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AESI5ACT 

Th€  current  methodology  for  col  dueling  computer  Risk 
Assessments  within  the  Department  of  the  Navy  is  examined  by 
studying  the  theories  and  philosophies  that  have  evolved 
from  the  perspective  cf  the  Federal  Government.  A  review  of 
the  Navy's  attitude  and  procedures  for  both  contractual 
assistance  and  inheuse  approaches  to  conducting  Risk 
Assessments  is  presented,  along  with  a  general  framework  for 
conducting  an  assessment  cr  the  computer  systems  at  the 
Naval  Postgraduate  School.  Attention  is  then  focused  on  the 
relative  merits  of  automated  and  manual  Risk  Assessment 
methods,  followed  by  an  outline  of  proposed  design  specifi¬ 
cations  fer  a  decision  support  system. 
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I.  IN  TBODOCTION 


The  advent  cf  computer  technology  during  the  previous 
two  decades  has  affected  virtually  every  aspect  of  govern¬ 
ment  and  private  industry.  As  technological  advances  fester 
the  availability  of  complex  systems  a:  lower  prices,  the 
integration  of  computer  systems  with  governmental  ar.d  indus¬ 
trial  processes  is  accelerated.  Applications  of  computer 
systems  range  from  relatively  routine  data  processing  tasks 
such  as  payroll,  accounting  packages,  and  inventory  control 
to  intricate  scientific  systems  controlling  space  flights 
and  decision  support  systems  assisting  managers  in  resolving 
unique  problems. 

The  pervasiveness  of  this  technology  has  created  many 
new  issues  for  management  concern  at  all  levels  of  govern¬ 
ment  and  industry.  Among  these  issues  is  the  subject  of 
security.  As  systems  become  more  and  more  complex,  organi¬ 
zations  which  utilize  them  are  becoming  mere  and  more  depen¬ 
dent  upon  them.  This  relationship  is  forerng 
computer-center  management  tc  devote  efforts  toward  improved 
security  in  ail  areas:  hardware;  software;  communications; 
personnel;  and  administration  [Baf.  1].  It  is  useful  to 
consider  exactly  what  we  mean  by  the  term  "security"  with 
respect  to  computer  systems.  According  to  aylie,  security 
is  "i  state  cf  mind  reached  when  one's  assets  are  receiving 
appropriate  protection.  Protection  has  three  facets  cf  equal 
importance.  Preventative  techniques  are  applied  to  prevent 
the  occurence  cf  threats.  Detection  techniques  are  applied 
to  ensure  that  all  threat  occurences  are  registered. 
Finally,  for  every  threat  cccurer.ce  there  must  be  an  appro¬ 
priate  response."  [Bef.  2]  These  definitions  present  a 
framework  on  which  a  computer  system  security  plan  may  be 


developed.  It  may  not  be  possible  to  design  a  system  which 
defeats  every  intrusion  attempt.  However,  an  adequate  goal 
for  many  organizations  might  be  to  raise  the  cost  cf  unau¬ 
thorized  cr  illegal  use  of  a  system  to  an  amount  so  high 
that  it  discourages  any  attempts.  While  this  goal  is  being 
pursued  with  vigor  today,  contemporary  literature  is  replete 
with  examples  of  computer  crime.  The  O.S.  Chamber  /f 
Commerce  estimates  that  if  computer  abuse  grows  proport, 
ally  with  the  number  cf  computers  in  operation,  there  v  1 
he  roughly  $160  million  annual  loss  by  1985  [Ref.  3]. 

Government  agencies  at  all  levels  and  private  enter¬ 
prises,  especially  banks,  must  be  concerned  with  the  threat 
of  sabotage  and  disruption,  not  only  theft.  The  financial 
institutions  participating  in  the  electronic  fund  transfer 
sytem  (2fTS)  in  the  U.S.  handle  amounts  of  money  equal  to 
the  national  debt  every  four  days  [Ref.  4],  The  potential 
for  economic  disaster  of  enormous  magnitude  exists.  The 
motivation  to  prevent  large-scale  penetration  and  disruption 
cf  systems  such  as  EFTS  is  providing  impetus  for  security 
research. 

The  need  for  computer  system  security  is  self-evident. 
The  magnitude  of  the  problem  is  enormous.  Partial  solutions 
to  this  problem  are  being  addressed  in  all  areas.  For 
example,  software  houses  have  developed  sophisticated  data 
access  control  packages.  Many  hardware  venders  are 
including  seme  type  of  security-control  feature  in  their 
products.  The  issue  of  computer  security,  however,  is  r.ot 
confined  to  technical  considerations  alone.  Management  must 
become  intimately  involved  in  this  area  if  meaningful 
progress  is  to  be  made.  A  commitment  by  top  management, 
clearly  indicating  to  the  entire  organization  the  emphasis 
that  must  be  placed  upon  security,  is  necessary.  Management 
at  all  levels  must  he  involved  vita  determining  policy  and 
implementing  measures  concerning  the  organization  of  a 


computer  security  program,  security  adminr srratrcn,  ns* 
assessments,  personnel  practices,  and  oack-up,  recovery  and 
disaster  planning. 

The  federal  government,  including  both  civilian  and 
military  agencies,  is  the  largest  user  of  ADP  facilities  in 
the  country  [Ref .  5].  Computer  usage  spans  a  7ast  diversity 
of  applications  such  as  World-Wide  Military  Command  and 
Control  System  (WWMCCS)  ,  Social  Security  System,  communica¬ 
tions,  federal  payroll  and  accounting  systems,  etc.  This 
immense  usage  has  logically  generated  interest  in  the 
security  of  these  particular  computer  systems.  In  fact,  the 
attention  being  devoted  to  the  security  of  computer  systems 
is  so  great  that  the  Office  of  Management  and  Budget  estab¬ 
lished  requirements  in  1978  that,  among  other  things,  every 
agency  iaplement  a  computer  security  program.  OMB  also 
defined  a  minimum  set  of  controls  to  be  incorporated  into 
each  agency's  computer  security  program.  [Hef.  6] 

Contemporary  literature  or.  computer  security  seems  to  be 
in  agreement  in  expressing  the  view  that  the  best  approach 
to  computer  security  is  the  "total  systems"  approach. 
Critical  areas  which  must  be  examined  include  hardware, 
software,  users,  pr cgrammme rs,  data,  input/output  documents, 
and  procedures.  Other  facets  cf  a  system  pertinent  to  a 
particular  organization  may  also  need  tc  be  examined.  One 
element  cf  the  "total  systems"  approach  is  the  conduct  of  a 
risk  assessment. 

what  is  a  risk  assessment?  Many  texts  offer  definitions 
which  differ  slightly  in  scope  and  degree.  Perhaps  the  most 
concise  and  applicable  is  Peter  3rcwne's  definition:  "A 

risk  assessment  is  an  analytic  process  designed  to  quantify 
the  EF  (data  processing)  security  required  by  an  organiza¬ 
tion.  It  considers  the  threats  to  information  and  the  loss 
that  would  occur  if  a  threat  were  to  materialize."  [Hef.  7] 
The  results  cf  a  risk  assessment  eraDie  an  organization  to 
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consider  solutions  tc  security  problems  which  are  cost- 
effective.  The  solutions  may  either  attempt  tc  reduce  the 
probability  cf  threats,  lessen  the  effects  of  various 
threats,  cr  aid  in  tte  recovery  from  a  "successful"  threat. 

An  organization  may  be  able  to  conduct  its  own  internal 
risk  assessment  if  personnel  assets  are  available. 
Specialists  in  computers,  security,  finance,  personnel  and 
operations  will  be  required.  Contracts  may  be  utilized  with 
one  of  several  commercial  compani  S3  o  *. ganizsd  conduct/  or 
to  provide  limited  assistance,  in  risk  assessments.  Chapter 
Thrae  will  address  this  issue  in  depth.  Of  course,  the 
active  participation  cf  management  is  crucial. 

A  risk  assessment  is  a  dynamic  concept.  It  should  be 
revised  periodically  to  account  for  any  changes  in  equip¬ 
ment,  software,  operating  procedures,  or  any  different 
element  which  might  affect  the  overall  security  of  the 
system.  In  particular.  Naval  activities  with  computer 
systems  ate  required  to  update  their  risk  assessments  at 
least  every  five  years  [Ref.  8]. 

The  federal  government,  as  wail  as  business  enterprises, 
must  approach  the  security  problem  ir.  an  economical  manner. 
The  risk  assessment  provides  a  logical  framework  to  conduct 
a  rational  analysis.  Management  must  provide  guidelines  to 
reach  answers  to  the  following  questions: 

1)  What  are  the  specific  results  required;  how  much 
security  is  required? 

2)  What  is  the  proper  balance  between  security  program 
cost  and  potential  benefits? 

3)  When  tradeoffs  car.  be  made  between  protection  and 
recovery,  hew  much  effort  should  be  expended  on 
each?  [ Ref.  9 ] 

Obviously  the  minimum  amount  cf  security  needed  is  to 
protect  those  items  that  are  required  to  keep  the  organiza¬ 
tion  operating.  The  security  manager  should  incorporate 


4 

. 


A 


•: 


t; 


2 


into  the  security  plan  those  functions  which  are  supported 
by  computer  facilities  and  essen**ai  to  the  continued  opera¬ 
tion  of  the  organization.  Additional  elements  may  also  be 
protected  if  it  is  economically  feasible  for  the  organiza¬ 
tion.  A  cost-benefit  analysis  may  be  applied  tc  the 
decision-making  process  concerning  additional  security 
measures. 

In  a  risk  analysis  situation,  it  is  necessary  tc  iden¬ 
tify  and  assess  the  degree  cf  threat  against  the  computer 
resources  cf  the  organization.  The  degree  of  threat  may 
determine  the  need  for  protection  of  some  asset.  The  amount 
and  cost  of  effort  tc  be  expended  in  examining  particular 
threats  should  be  proportional  to  the  potential  loss  caused 
by  such  threats.  Threats  can  usually  be  grouped  into  one  or 
mere  cf  the  following  categories: 

1)  natural  hazards  and  accidents  such  as  fire,  earth¬ 
quakes,  hurricanes,  etc. 

2)  internal  accidents  and  breakdowns  such  as  programmer 
and  operator  errors,  hardware  failures,  etc. 

3)  violent  intentional  actions  such  as  sabotage, 
strikes,  etc. 

4)  ncn-violsnt  intentional  actions  such  as  fraud, 
embezzlement,  and  theft.  £Hef.  10] 

The  potential  loss  associated  with  each  threat  must  also 
be  examined  .  Some  consistent  quantifying  standard  must  be 
applied  to  each  threat  so  that  comparisons  between  losses 
can  be  made.  Similar  to  threats,  losses  may  also  be  grouped 
into  four  general  categories: 

1)  delayed  processing-  the  expanse  incurred  when  a 
computer  application  is  not  processed  on  time  . 

2)  loss  of  data  processing  assets-  these  are  the  orga¬ 
nizational  assets  in  the  custody  of  the  data  processing 
unit.  Data  are  the  most  valued  assets  ana  loss  cf  data 
may  cause  irreparable  harm. 


3)  less  of  organization  assets  by  means  of  computer 
application  s- when  assets  such  as  accounts  receivable, 
negotiable  securities,  etc.,  are  controlled  by  a 
computer,  they  are  vulnerable  to  fraud  and  manipula¬ 
tion. 

4)  loss  of  data  confidentiality-  disclosure  of  personal 
cr  proprietary  data  to  unauthorized  persons  can  cause 
economic  loss,  dilution  of  planning  efforts,  loss  of 
employee  morale,  and  legal  action.  [Ref.  11] 

The  potential  threats  and  the  losses  associated  with  each 
threat  must  be  considered  together.  2ach  pairing  of  threat 
and  less  should  be  ranked  according  to  their  impact  upon  the 
organization.  After  this  ranking  has  been  developed,  the 
process  of  examining  cost-effective  countermeasures  can  be 
studied. 

This  chapter  has  provided  an  overview  of  the  nature  of 
the  computer  security  problem  today. In  particular,  the 
concept  cf  risk  assessments  has  been  introduced  and  its 
potential  benefits  to  organizations  have  been  considered. 
The  subject  of  risk  assessment  and  related  ideas  will  be 
addressed  in  greater  detail  in  later  chapters.  chapter  Two 
will  detail  the  history  and  evolution  of  risk  assessment 
requirements  within  the  Department  of  Defense  and  the 
Department  cf  the  Navy.  Chapter  Three  will  examine  various 
points  which  must  be  considered  when  an  organization  is 
deciding  whether  to  do  an  '•in-house'1  risk  assessment  cr  to 
contract  this  function  with  a  commercial  company.  A  general 
framework  for  conducting  a  risk  assessment  at  the  Naval 
Postgraduate  School  will  be  discussed  in  Chapter  Four. The 
framework  will  be  based  upon  the  guidelines  promulgated  in 
OPNAVINST.  5239. 1A.  Chapter  Five  will  examine  how  to 
design  a  decision  support  system  to  assist  management  in 
conducting  a  risk  assessment.  Basic  design  modules  will  be 
presented  and  some  particular  problems  associated  with  data 


hase  management  will  he  considered.  The  field  of  cca:i:er 
security  in  cjneral,  and  risk  assessments  in  particular,  has 
advanced  to  such  a  degree  that  several  companies  new  offer 
automated  risk  assessment  systems.  A  brief  consideration  of 
these  systems  and  a  comparison  of  their  attributes  vis-a-vis 
manual  systems  will  also  be  presented  in  Chapter  Five.  The 
final  chapter  will  summarize  the  pertinent  points  covered  in 
this  thesis.  Some  conclusions  will  be  drawn  about  the  state 


II.  DEJgABTSEN£  OF  DB  FENS  E/D  SPARTMENT  OF  THE  NAVY  DIRECTIVES 


A.  GENERAL 

Frcm  the  outset,  the  Federal  Government  r.as  beer,  a 
pioneer  in  the  development  of  advanced  computer  systems. 
"The  first  successful  large  scale  data  processing  installa¬ 
tion  was  made  in  the  early  fifties  at  the  Census  Bureau,  and 
the  initial  impetus  toward  programming  languages  for  busi¬ 
ness  applications  came  from  Department  of  Defense  support  of 
the  COBOL  programming  language  in  the  sixties"  [Ref.  12]. 
From  that  point  cn,  the  rapid  growth  of  computer  technology 
and  the  government's  reliance  on  accurate  computing  systems 
rose  at  an  exponential  rate.  Poor  accounting  and  managerial 
control  practices,  however,  have  brought  about  extreme  inac¬ 
curacies  in  the  data  pertaining  to  computer  hardware  and 
software  inventories  held  by  the  Federal  Government.  In 
1976,  estimates  of  the  amount  of  money  spent  on  data 

processing  were  decidedly  vague.  "The  General  Accounting 
Office  (GAC)  was  able  only  to  bracket  Federal  Data 
Processing  spending  as  between  33  billion  and  $10  billion 
annually.  Mere  recently,  the  Office  of  Management  and  Budget 
(OMB)  has  cited  a  figure  of  $5.5  billion,  and  the  General 
Services  Administration  (GSA)  has  estimated  the  cost  of 
software  development  and  maintenance  alone  at  $2.2  billion." 
[Ref.  12]  A  large  percentage  of  these  expenditures  were 
attributed  to  the  DCD.  In  1991,  the  number  of  installed 
computer  systems  was  estimated  to  be  around  15,000,  while 
the  number  of  personnel  working  in  the  computer  field  was 
estimated  at  100,000  [Ref.  12].  These  figures,  however, 
gross  approximations. 
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Sines  the  science  cf  computer  technology  was  a  relatively 
n 2w  phenomenon  at  the  time  the  government  began  to  explore 
its  possibilities,  the  development  of  government  computer 
systems  was  done  in  a  rather  piecemeal  fashion,  with  little 
regard  to  the  managerial  aspects  of  designing  and  imple¬ 
menting  computer  systems.  Ihe  emphasis  was  on  buying/ 
developing  and  getting  the  systems  into  operation  as  fast  as 
possible  in  order  to  show  that  a  functional  entity  had 
resulted  from  all  the  monetary  and  personnel  resources  that 
had  been  expended.  as  a  result  of  this  mismanagement  (or 
rather  nen-managemeat) ,  government  agencies  were  faced  with 
computer  systems  that  were  inflexible,  inaccurate,  and 
subject  tc  rapid  obsclasence.  The  public  outcry  over  the 
amount  of  tax  dollars  spent  on  mismanaged  computer  resources 
led  the  Federal  Government  to  issue  policy  directives 
addressing  computer  management  from  the  initiation  of 
requirements  analysis  to  final  test  and  implement aticn. 


B.  GCVEHNHENT  COHCEBNS 

At  abcut  this  same  time,  there  was  a  growing  concern 
over  ths  security  vulnerabilities  inherent  in  these  new 
computer  systems.  Although  hardware  and  software  technology 
had  been  progressing  at  a  rapid  rate,  little  consideration 
had  been  given  to  computer  security  technology.  However, 
with  the  Ercoks  Act  cf  196  5,  the  Office  of  Management  and 
Budget  (CME)  had  been  assigned  responsibilities  for  the 
oversight  and  policy-making  functions  applicable  to  computer 
systems  development  and  acquisition.  Thus,  "in  1972,  —  0M3 
urged  private  industry  --  hardware  manufacturers,  software 
houses  and  related  service  industries  —  to  make  greater 
capital  investments  in  computer  security.  At  the  time,  the 
Federal  Government  was  concerned  that  its  inability  to 
protect  data  in  computer  systems  --  except  at  very  great 


expanse  —  was  limiting  its  ability  to  realize  the  benefits 
cf  technology."  [Ref.  13]  In  December  of  that  same  year, 
the  Department  of  Defense  issued  DDD  Directive  5200.23  enti¬ 
tled  "Security  Requirements  for  Automatic  Data  Processing 
(ADP)  Systems".  The  purpose  of  the  directive  was  tc  estab¬ 
lish  "uniform  policy  for  protecting  classified  data  stored, 
processed,  or  used  in,  and  classified  information  communi¬ 
cated,  displayed,  cr  disseminated  by  an  Automatic  Data 
Processing  (AD?)  System"  [Ref.  14].  Although  DOD  5200.28 
does  not  directly  address  risk  assessments,  it  does  require 
that  the  heads  of  DOE  components  provide  for  the  appointment 
of  an  ADP  Security  Officer,  who  will  later  play  an  important 
role  in  conducting  risk  assessments  for  Navy  computer 
facilities. 1 

In  the  mid-1970,s,  OMB  became  even  more  concerned  with 
encouraging  the  growth  of  computer  security  technology  since 
the  Privacy  Act  of  1974  set  "forth  a  series  of  requirements 
governing  Federal  agency  personal  record-keeping  practices" 
[Ref.  15].  These  requirements  increased  the  need  tc  provide 
security  for  the  personal  data  maintained  in  Federal 
computer  systems. 

C.  LEGISLATION 

The  Brocks  Act  also  assigned  otner  agencies  responsibili¬ 
ties  for  contributing  to  the  Federal  ADP  Programs.  The 
National  Bureau  of  Standards  (NBS)  ,  under  the  Secretary  of 
Commerce,  was  tasked  with  providing  "leadership,  technical 
guidance,  and  coordination  of  government  efforts  in  the 
development  of  guidelines  and  standards"  [Ref.  19].  in 


*The  terms  "Risk  Analysis"  and  "Risk  Assessment"  can  be 
used  interchangeably.  While  early  government  directives  used 
"Risk  Analysis",  it  is  new  more  common  to  use  "Risk 
Assessment" . 


areas  pertaining  to  ADP  and  ADP  Security.  The  basic  philo¬ 
sophy  behind  the  MBS  work  in  ADP  Security  was  reflected  in 
Federal  Information  Processing  Standards  Publication  (?IPS 
PUB)  31  of  June,  1974:  "Data  confidentiality  and  computer 
security  are  dependent  upon  the  application  of  a  balanced 
set  cf  managerial  and  technological  safeguards.  within  the 
context  of  a  total  security  program,  the  NBS  is  pleased  to 
provide  guidelines  for  ADP  Physical  Security  and  Risk 
Management  a  Vila  tie  for  use  by  Federal  agencies"  [Bef.  19]. 

The  concept  of  Risk  Ma nagement  was  introduced  at  this 
time  to  provide  federal  agencies  with  guidelines  for 
applying  management  principles  to  the  ris*s  associated  with 
the  acquisition  cf  hardware  and  software.  Although  FIPS  PUB 
31  specifically  addresses  physical  security  programs,  it 
also  touches  upon  procedural  aspects,  contingency  planning, 
supporting  utilities,  computer  reiia oility ,  disaster  prob¬ 
abilities,  security  awareness  programs,  and  risk  analysis 
met hcdolcgies.  This  publication  was  one  of  the  first  to 
provide  specific  recommendations  on  implementing  comprehen¬ 
sive  computer  security  programs.  It  is  important  to  note, 
however,  that  its  contents  were  strictly  composed  of  recom¬ 
mendations  and  guidelines  -  they  aid  not  constitute  a 
government  directive  mar.da  tin  a  computer  security  require¬ 
ments  on  government  agencies.  The  publication  was  edited  by 
Susan  K.  Reed  of  the  Systems  and  Software  Division  of  MBS. 
She  later  authored  a  government  document  on  conducting  risk 
analyses  which  would  be  included  as  an  addendum  to  DOD 
5200. 28-M,  the  Department  of  Defense  ADP  Security  Manual. 
This  xanual  will  be  discussed  in  more  detail  in  a  subsequent 
section. 

It  is  interesting  to  note  that  FIPS  PUB  31,  published  in 
1974,  covers  in  great  detail  those  security  practices  that 
are  advocated  by  more  recent  publications.  Unfortunately, 
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the  publication  has  teen  overshadowed  by  current  directives 
that  dictate  what  must  be  done  but  not  how  to  dc  it.  For 
example,  conventional  risk  assessments  require  an  analysis 
cf  the  potential  threats  to  an  ADP  facility  caused  by  wind¬ 
storms,  hurricanes,  and  tornadoes.  Such  information  could 
conceivably  be  obtained  from  the  National  leather  Service, 
but  it  is  already  provided  in  FIPS  PUB  31.  In  Key  West, 
Florida,  to  be  specific,  the  annual  probability  that  a 
hurricane  will  occur  is  13%  (Ref.  20].  This  figure  could  be 
used  as  direct  input  to  the  threat  analysis  form  for  the 
current  CCD-advocated  risk  assessment  methodology. 

To  start  a  security  program,  the  FIPS  encourages  all 
government  agencies  to  "perform  a  preliminary  risK  analysis 
to  identify  major  problem  areas  and  select  interim  security 
measures  as  needed  to  correct  major  problem  areas" 
[Ref.  21].  The  idea  behind  this  is  that,  since  computer 
security  is  an  ongoing  process,  the  most  obvious  security 
problems  should  be  handled  in  an  expeditious  manner  -  agen¬ 
cies  need  net  and  should  not  wait  until  a  comprehensive  risk 
assessment  has  been  completed  prior  to  tackling  the  serious 
security  problems.  In  the  meantime,  a  preliminary  assess¬ 
ment  should  be  done  to  help  isolate  those  problems. 

The  actual  risk  assessment  methodology  presented  in  the 
FIPS  is  a  sound  one.  It  gives  an  excellent  overview  of  the 
means  by  which  a  risk  assessment  may  be  conducted,  complete 
with  charts,  tables,  and  figures  that  the  user  may  apply  in 
calculating  the  final  Annual  Loss  Expectancy  (ALE)  value. 
However,  the  publication  is  somewhat  weak  when  it  comes  to 
describing  the  format  or  layout  cf  an  agency’s  actual  risk 
assessment  document. 
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D.  DEFINITIONS 


Before  going  into  the  specific  risk  assessment  method¬ 
ology  outlined  in  the  FIPS,  it  is  appropriate  to  define 
certain  terms  which  are  common  to  most,  if  r.ct  all, 
government-endorsed  risk  assessment  methodologies  : 

THBEAT  -an  overt  or  covert  activity  which  may  causa 
less  or  damage  tc  a  computer  facility; 

LOSS  -the  potential  for  being  deprived  of  computer 
assets  or  services; 

VOL  NEB  ABILITY  -the  weakness  inherent  in  a  computer 
system,  which  makes  it  susceptibia  to  loss  or  damage; 

ANNUAL  LOSS  EXPECTANCY  (ALE)  -an  estimate  of  the  amount 
cf  money  that  a  computer  facility  could  potentially 
lose  in  a  year  if  threats  against  the  facility  wer*» 
realized. 

E.  FIPS  POB  31  METHODOLOGY 

Ihe  FI ES  methodolgy  is  basically  a  three-step  process  : 
1.)  Make  an  estimate  of  the  potential  losses  to  which  the 
computer  facility  is  exposed;  2.)  Perform  an  analysis  of  the 
threats  which  may  be  made  against  the  facility;  and  3.) 

Combine  the  estimates  of  potential  loss  and  probability  of 

less  tc  produce  an  ALB  value. 

1 .  Estimating  Less 

Step  one,  estimates  of  potential  losses,  is  to  be 
done  ir.  terms  of  five  distinct  categories  ;  "  (1)  physical 

destruction  or  theft  of  physical  assets;  (2)  loss  or 

destruction  cf  data  and  program  files;  (3)  tn eft  cf  informa¬ 
tion;  (4)  theft  of  indirect  assets;  and  (5)  delay  or  preven¬ 
tion  of  computer  processing”  [Sef.  21].  The  end  products  of 


this  procedure  are  an  identification  of  the  comparer  facili¬ 
ty's  assets  and  dollar  values  for  loss  estimates. 

Cf  the  five  categories  listed,  the  first  is  undoub¬ 
tedly  the  most  straightforward.  Replacement  costs  for  such 
items  as  hardware,  communications  equipment,  supplies,  and 
the  building  itself  should  be  entered  into  the  command's 
inventory  files  as  required  by  GSA.  Unfortunately,  many 
federal  agencies  have  neglected  to  maintain  inventory  files 
over  the  years.  One  of  the  fringe  benefits  of  a  risk 
assessment  is  that  such  inventories  must  be  generated,  thus 
enhancing  a  command's  resource  management  capabilities. 
Once  these  inventories  have  been  made  available,  the  esti¬ 
mate  cf  less  for  a  particular  piece  of  equipment  corresponds 
to  its  replacement  cost.  For  example,  if  a  high-speed  line 
printer  costs  $5000,  then  its  loss  estimate  would  be  the 
same  -  the  command  has  the  potential  for  losing  $5000  if  the 
printer  were  to  be  destroyed  or  stolen. 

In  the  second  and  third  categories,  less  or  destruc¬ 
tion  cf  data  and  program  files  and  theft  of  information,  a 
great  deal  cf  ambiguity  occurs.  The  question  which  must  be 
answered  is  :  What  is  the  value  of  the  data  contained  in  the 
computer  system  ?  This  is  a  question  which  has  received  a 
great  deal  of  attention  in  recent  years.  The  Commander, 
Naval  Data  Automation  Command  (COMNAVDAC)  ,  spent  *  signifi¬ 
cant  amount  cf  time  and  money  in  trying  tc  bring  the  ques¬ 
tion  of  the  value  of  data  into  perspective.  Seme 
consideration  was  given  to  standardizing  data  value  based  or. 
the  number  cf  lines  cf  code  and/or  security  classification. 
A  single  line  of  code  in  a  100-line  program  file  might  be 
valued  at  $10,  for  example.  The  loss  or  destruction  cf  the 
file  wculd  thus  contribute  $1000  to  the  agency's  AL2.  In 
essence,  it  would  cost  the  command  $1300  to  reconstruct  the 
file.  In  a  similar  manner,  a  word  of  SECRET  or  TOE  SECRET 
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cede,  if  compromised  cr  stolen,  might  be  valued  at  3100  and 
$200  respectively.  Ey  standardizing  these  values,  computing 
the  ALE  for  most  types  of  computer  software  would  be  a 
simple  matter  of  mathematical  calculation,  with  lines  of 
code  (the  amount  of  money  it  would  cost  a  programmer  to 
reproduce  the  code)  being  an  absolute  value,  and  classified 
coda  representing  a  relative  value.  In  theory,  such  methods 
have  a  sound  basis.  In  practice,  however,  the  application 
cf  such  methods  has  proven  to  be  rather  unrealistic.  In 
fact,  CCMNAVDAC  has  recently  abandoned  its  attempts  to 
provide  for  standardization  in  favor  of  more  practical 
methods. 

"If  the  ADP  system  is  used  to  control  other  assets 
such  as  cash,  items  in  inventory,  or  authorization  for 
performance  of  services,  then  it  may  also  be  used  to  steal 
such  assets."  [Ref.  22].  These  assets  are  known  as  indi¬ 
rect  assets,  and  their  loss  estimate  corresponds  to  the  real 
value  cf  the  asset. 

In  estimating  the  potential  loss  caused  by  the  delay 
cr  prevention  cf  computer  processing,  several  considerations 
must  be  addressed.  Some  losses  may  be  estimated  in  a  rela¬ 
tively  straightforward  manner.  Obvious  examples  involve  a 
failure  to  process  payment  checks  promptly,  thereby 
preventing  the  exercise  of  a  prompt  payment  discount  under  a 
procurement  contract,  or  delays  in  an  inventory  system  which 
may  lead  to  idle  manpower  at  a  warehouse  [Ref.  22].  In  a 
situation  where  a  computer  facility  functions  as  a  service 
agency,  the  loss  estimate  would  be  based  on  the  revenues 
lost  as  a  result  of  the  customers  being  denied  access  to  the 
computer  system.  On  the  other  hand,  "...in  those  situations 
where  a  delay  would  more  or  less  halt  operations  of  an 
agency, .. .use  the  daily  operating  cost  cf  an  agency  as  a 
rough  rule-of-thumb  estimate  of  the  cost  of  delayer 
processing"  [Ref.  22]. 


In  general,  there  are  time  ranges  or  limits  within  which 
loss  estimates  will  differ.  If  service  ns  denied  but  -he 
system  can  te  brought  back  up  witnin  a  reasonable  amount  of 
tame,  it  is  possible  that  no  loss  will  be  incurred  during 
that  time  period.  However,  after  a  certain  period  of  time 
during  which  the  computer  system  has  not  been  returned  tc 
service,  losses  will  be  incurred,  and  in  general,  such 
losses  will  grow  in  proportion  to  the  duration  of  the  delay. 
The  FIES  PUB  stresses  the  importance  of  establishing  this 
’•maximum  'nc  loss*  delay  time  and  an  estimate  of  the  median 
time  to  reconstruct  the  ADP  facility  after  total  destruc¬ 
tion”  [Ref.  22].  Once  these  time/cost  boundaries  have  beer. 


TABLE  I 
Loss  Exposure 


Loss  of 
Data 

Theft  cf 
Info . 

Theft  of 

A  5  SS 1 5 

Delayed 

Processing 

Yes 
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NO 

Extreme 

Yes 

Yes 

Yes 

Moderate 

Me 

Yes 

Yes 

Moderate 

M  o 

Yes 

Yes 

Low 

MO 

Mo 

Mo 

Very  Low 

made,  then  the  time  period  can  be  divided  into  various 
ranges  and  less  estimates  can  be  assigned  accordingly. 

After  conducting  a  preliminary  estimate  cf  all  potential 
losses,  the  task  might  be  simplified  by  presenting 
collected  data  in  tabular  form,  as  shown  ir.  Table 
extracted  from  PIPS  EUB  31. 
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TABLE  II 

Sources  for  Threat  Information 


Threat 


Sources  of 
Information 


Firs 


Flood 

Earthquake 


Windstorm 


Fewer  Failure 


Air  Condi¬ 
tioning  Failure 

Communica¬ 
tions  Failure 


ADP  Hardware 
Failure 


Intruders, 
Vandals,  etc. 


Compromising 
Zmahat  ions 


Building  fire  mar¬ 
shal  ana  local  fir< 
department 
Army  Corps  cf 
Engineers 
National  Earth¬ 
quake  Information 
Center 

National  Oceanic 
and  Atmospheric 
Administration  and 
local  National 
Weather  Service 
Office 

Building  Engineer 
and  local  public 
utility 

Building  Engineer 
and  air  condi¬ 
tioning  vendor 
Federal  Tele¬ 
communications 
System,  building 
and  local  telephor. 
company 

Hardware  vendors 
and  Federal  Supply 
Service 

3uilding  manager, 
security  director 
and  the  Office  of 
Federal  Protective 
Service  Man¬ 
agement,  GSA. 
Hardware  vendors 
and  the  Office  cf 
Feisrai  Protective 
Service  Man¬ 
agement,  GSA. 
System  Design,  In¬ 
ternal  Audit  and 
Personnel  Division 


Internal  Theft 
or  Misuse 


2.  Evaluat lag  Threats 


In  proceeding  with  the  second  step  of  th 
assessment,  that  of  evaluating  tne  threats  gainst 
facility,  the  ADP  Security  Planner  (re.  the  person 
sible  fcr  conducting  the  overall  risk  assessment) 
solicit  the  help  of  fire  marshals,  hardware  vendors, 
government  agencies,  in  house  personnel,  and/or  any 
or  person  who  might  contribute  inputs  to  a  threat 
tion.  Table  II  provides  a  list  of  sources  of  info 
for  different  categories  of  threats. 


e  risk 
the  ADP 
re  spon- 
skculd 


ctner 


agency 

evaiua- 


r mat non 


Although  the  PIPS  gives  little  information  on  the 
specific  numerical  figures  to  use  in  quantifying  threats,  rt 
does  provide  specific  guidance  on  determining  threat  prob¬ 
abilities.  Figure  2.1,  for  example,  a  seismic  risk  map  of 
the  United  States,  gives  the  user  a  rough  idea  of  the  long¬ 
term  hazards  caused  by  earthquakes. 


Figure  2.  1  Seismic  Bisk  Nap 
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«  Calculating  the  Annual  Loss  E  x? act ancy  (ALE) 

The  final  step  in  the  risk  assessment  process 
itself,  although  follow-on  action  is  understood,  involves 
the  determination  of  the  ALE.  This  can  be  accomplished  (and 
most  readily  understood)  by  constructing  a  matrix  of  threats 
and  the  lcsses  which  might  be  associated  with  them.  Table 
III  shows  a  computation  for  estimating  the  expected  lcsses 
that  might  be  caused  by  fire  damage. 

Construction  cf  such  a  table  is  a  common  procedure 
in  operations  research  and  management  sciences  where  the 
objective  may  be  to  minimize  losses  (as  in  this  case)  or 
maximize  profits.  The  occurrence  probabilities  shown  (.10, 
.05, .005)  may  be  derived  by  analyzing  the  facility's  fire 
safety  precautions,  a  procedure  for  which  the  PIPS  PUB  gives 
detailed  guidance. 

The  dollar  amounts  for  loss  may  be  computed  as 
described  earlier  in  the  chapter.  Once  these  figures  have 
teen  made  available,  estimates  for  the  total  potential  less 
and  the  annual  loss  for  each  category  can  be  calculated  by 
multiplying  the  occurrence  probability  by  the  loss  figures. 
Similar  tables  can  be  constructed  for  natural  disasters  such 
as  earthguakes,  tornadoes,  volcanic  eruptions,  floods,  and 
ethers. 

Open  completion  of  the  estimation  of  the  ALE  for  all 
categories  cf  less,  the  security  manager  should  have  a 
clearer  understanding  cf  the  coupling  of  threats  and  losses 
within  his  facility.  He  is  then  in  a  position  to  prioritize 
his  werk  in  the  area  of  computer  security  countermeasures. 
In  general,  remedial  measures  should  be  applied  to  these 
areas  in  which  the  loss  potential  is  the  greatest.  The  end 
result,  then,  of  the  risk  assessment  process  is  a  cost- 
benefit  analysis  of  expending  funds  towards  the  "securing" 
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TABLE  III 

Estimating  Firs  Loss 
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88,000 
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of  a  specific  computer  security  weakness.  If,  for  example. 


the  ALE  for  building 

damage 

caused  by 

fire  i 

s  S  9,700  ,  the 

agency  should  be  w 

illing 

to  spend 

up  to 

that  amount  in 

providing  remedial 

measure 

s  to  lessen 

that 

loss  potential. 

The  risk  assessment 

will  t 

hus  provide 

the 

security  manager 

with  the  ammunition  he  needs  to  get  top  management  support 
on  funds  for  security  countermeasures. 

The  preceding  synopsis  of  the  FIPS  methodology  might  seem 
to  be,  as  presented,  a  relatively  straightforward  process. 
However,  the  FI  PS  EGB  clearly  states,  "...this  is  net  an 
exact  science.  Indeed,  it  is  quite  likely  that  cne  will 
have  to  reappraise  threats  and  losses  more  than  cr.ce, 
concentrating  on  the  areas  initially  identified  as  most 


critical,  before  the  less  expectancy  estimate  reacr.es  a 
satisfactory  level  of  confidence.”  [Ref.  23] 

The  level  of  detail  provided  fer  the  above  FIPS  PUB  meth¬ 
odology  will  serve  as  a  point  of  reference  for  descriptions 
of  subsequent  methodologies.  Other  risk  assessment  metho¬ 
dologies  will  be  discussed  in  terms  of  how  they  differ  from 
the  one  described  in  FIPS  PUB  31. 

F.  SUBSEQUENT  GOVERNMENT  DIRECTIVES 

Shortly  after  the  release  of  FIPS  PUS  31,  the  Privacy  Act 
cf  1974  was  enacted.  OMB  Circular  A-108,  distributed  six 
months  later,  was  written  to  assign  responsibilities  for  the 
security  cf  the  personal  records  maintained  by  Federal  agen¬ 
cies.  Under  this  directive,  the  term  "system  of  records" 
was  defined  as  "...a  group  cf  any  records  under  the  control 
cf  any  agency  from  which  information  is  retrieved  by  the 
came  of  the  individual  or  by  some  identifying  number, 
symbol,  or  other  identifying  particular  assigned  to  the 
individual”  [Ref.  16],  Since  computer  and  word  processing 
systems  are  perfect  vehicles  for  data  storage  and  retrieval, 
it  was  ana  is  only  natural  that  they  would  be  used  for  the 
maintenance  of  personal  records.  A-108  further  mandated 
that  reasonable  administrative,  technical,  and  physical 
safeguards  are  established  to  ensure  that  personal  records 
are  only  disclosed  to  those  who  are  authorized  to  have 
access  to  them  [Ref.  17].  This  implies  that  security  coun¬ 
termeasures  must  be  in  effect  for  ail  federally-owned 
computer  systems  maintaining  personal  data.  The  directive 
also  required  that  the  GSA  "revise  computer  and  telecommuni¬ 
cations  procurement  policies  to  provide  that  agencies  must 
review  all  proposed  equipment  and  services  procurements  to 
assure  compliance  with  applicable  provisions  of  the  Act" 
[Ref.  18].  This  was  the  first  of  many  government  directives 
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requiring  that  federal  agencies  address  security  issues  in 
their  computer  development  and  acquisition  plans.  However, 
outside  cf  FIPS  PUB  31,  the  distribution  and  knowledge  of 
which  was  very  limited,  the  Federal  Government  was  slew  to 
document  specific  policies  and  procedures  for  implementing 
computer  security  programs. 

Finally,  three  years  later  in  July,  1978,  OdB  Circular 
A-71,  entitled  "Security  of  Federal  Automated  Information 
Systems",  was  approved  for  distribution.  Ir.  general,  the 
purpose  cf  A-7 1  was  to  promulgate  "policy  and  responsibili¬ 
ties  for  the  development  and  implementation  cf  computer 
security  programs  by  executive  branch  departments  and  agen¬ 
cies"  [Bef.  24].  This  circular  documented  the  requirement 
that  periodic  risk  assessments  be  conducted  by  each  federal 
agency  operating  a  computer  facility.  Although  A-71 
provided  no  guidelines  on  how  to  conduct  a  risk  assessment, 
it  did  require  that  a  risk  assessment  be  carried  cut  or 
revised  under  any  of  the  following  conditions  : 

1. )  prior  to  the  approval  cf  design  specifications  for 

new  computer  installations; 

2. )  whenever  there  is  a  major  change  to  the  physical 

facility,  hardware  or  software;  or 

3. )  at  periodic  intervals  of  time,  not  exceeding  five 

years,  if  no  risk  assessment  has  been  performed  dur¬ 
ing  that  time. 

[Bef.  25] 


This  directive  had  serious  consequences  for  all  federal 
agencies.  For  most  agencies,  the  third  condition  was  the 
one  under  which  the  risk  assessments  would  be  conducted. 
Taose  agencies  which  had  yet  to  perform  a  risk  assessment 


interpreted  the  condition  as  meaning  chat  they  had  a  five- 
year  deadline  on  the  requirement.  Unfortunately,  this 
slowed  response  from  many  federal  agencies. 

Tc  promulgate  the  requirements  of  A-71,  the  Department  of 
the  Navy  issued  OPNAVINST  5239.1  in  April,  1979.  This 
instruction  specified  the  A-71  requirements  for  all  DON 
activities.  Although  the  instruction  did  little  to  augment 
the  policies  provided  by  A-71,  it  did  require  that  all  DON 
activities  operating  computer  installations  appoint  an  ADP 
Security  Officer  who  would  be  responsible  for  ensuring  that 
a  risk  assessment  wculd  be  conducted  on  a  periodic  basis. 
Two  relevant  enclosures  that  were  included  as  part  of 
CPNAVINST  5239.1  were  DOD  5  200.28-B  entitled  ''Techniques  and 
Procedures  for  Implementing,  Deactivating,  Testing,  and 
Evaluating  Secure  Resource- Sharing  ADP  Systems",  and  a  set 
cf  guidelines  for  conducting  risk  assessments  which  was 
edited  by  Susan  K.  Eeed.  The  former,  constituting  the  DOD 
AD?  Security  Manual,  provided  standardized  guidelines  for 
securing  computer  systems  -  it  did  not  address  risk  assess¬ 
ments;  the  latter,  however,  provided  an  excellent  generic 
framework  fcr  conducting  risk  assessments.  It's  merit  was 
more  in  facilitating  the  security  officer's  understanding  of 
the  risk  assessment  model  than  in  the  actual  methodolgy 
proposed.  The  technique  presented  o y  the  methodology  is 
similar  tc  that  presented  in  FIPS  PU3  31,  but  is  a  more 
mathematically-oriented  model.  These  guidelines  were  later 
released  in  August,  1979,  as  FIPS  PUB  65,  "Guideline  for 
Automated  Data  Processing  Risk  Analysis". 

G.  PIPS  EOB  65  BBT  HC  COLOG  I 

In  general,  FIES  PUB  65  "explains  the  reasons  for 
performing  a  risk  analysis,  details  the  management  involve¬ 
ment  necessary  and  presents  procedures  and  forms  to  be  used 


for  risk  analysis  and  cost  effective  evaluation  of  safe¬ 
guards”  (Ref.  26].  Unlike  FIPS  PUB  31,  this  NBS  publication 
gives  no  guidance  on  estimating  specific  loss  probabilities 
(ie.  there  are  no  seismic  risk  maps  or  tables  with  hurricane 
probabilities  for  various  regions)  ,  but  it  does  provide  a 
better  and  more  detailed  explanation  of  the  quantitative 
measures  and  forms  required  for  a  risk  assessment.  In 
short,  FIPS  PUB  65  covers  the  ambiguities  present  in  FIPS 
PUB  31.  Ihe  two  in  combination  provide  a  powerful  framework 
under  which  a  viable  risk  assessment  can  be  conducted. 

Like  most  methodologies,  the  one  advocated  by  FIPS  PUB  65 
recommends  that  a  preliminary  security  analysis  be  performed 
in  order  to  identify  a  computer  installation's  assets, 
threats,  vulnerabilities,  and  thus,  the  facility's  security 
posture.  Three  specific  products  will  result  from  this 
preliminary  analysis  : 

1. )  a  list  of  asset  replacement  costs; 

2. )  a  list  of  threats  to  which  the  facility  is  vulner¬ 

able;  and 

3. )  a  list  of  existing  security  measures.  [Ref.  27] 

These  products,  once  assigned  quantitative  measures,  will 
form  the  basis  for  the  computation  of  the  ALE  (s)  . 

The  next  step  in  the  FIPS  methodology  is  to  quantify  the 
measures  for  impact  and  the  frequency  of  occurrence  for 
threats.  Ihe  impact  cf  an  event  is  defined  as  the  exact 
amount  cf  damage  it  could  cause,  while  the  frequency  of 
occurrence  refers  tc  the  exact  number  of  times  the  event 
could  occur.  [Ref.  28]  The  common  denominator  selected  for 
the  measures  is  monetary  value,  and  a  year  is  the  time 
period  against  which  frequencies  of  occurrence  will  be 
assessed.  To  simplify  such  quantitative  measures,  estimates 
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for  impact  and  frequency  are  rounded  off  to  factors  ef 
The  range  cf  measures  for  both  categories  is  shown  in 

17. 


TABLE  17 

Orders  of  Magnitude  of  Estimated  Impact  and  Frequency 


I MPACT  i 

$10 
$100 
$1000 
$10,  000 
$100,000 
$1,000,  000 
$io,ooo;ooo 
$  100,000,000 


FREQUENCY: 

Once  in  300  years 

Once  in  30  years 

Once  in  3  years  (1000  days) 

Once  in  100  days 

Once  in  10  days 

Once  per  day 

10  times  per  dav 

100  times  per  day 


The  FTPS  emphasizes  that  rounding  off  the  figures  will 
not  have  a  significant  effect  on  the  overall  ALE.  The  rele¬ 
vance  lies  in  orders  of  magnitude  rather  than  in  absolute 
figures.  Thus,  ’’there  will  be  nc  significant  difference  in 
the  overall  exposure  whether  the  damage  from  a  certain  event 
is  estimated  at  $110,000  or  $1 45,000. ..  (or)  ..  .if  the 
frequency  of  an  event  is  expected  to  be  twelve  times  a  year 
cr  thirty”  [Bef.  29].  Once  the  impact  and  frequency 
measures  have  been  determined,  the  ALE  can  be  readily  calcu¬ 
lated  using  the  following  formula  : 
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LOSS  *  IHPACT(I)  X  FREQUENCY  OF  OCCURRENCE  (F) 

Ic  use  this  formula,  however,  it  is  first  necessary  to 
index  the  impact  (i)  and  the  frequency  (f)  measures  from 
Table  IV.  The  resulting  indices  are  shown  in  Taole  V. 


TABLE  V 

Table  for  Selecting  of  Values  of  i  and  f 


If  the  estimated  cost  impact  of  the  event  Li 

$10,  let  i  =  1 

$100,  let  i  =  2 

$1000,  let  i  =  3 

$10,000,  let  i  =  4 

$100,000,  let  i  *  5 

$  1,000,000,  let  i  =  6 

$10,000,000,  let  i  *  7 

$1  00,000,000,  let  i  =  8 

If  the  estimated  frequency  of  occurrence  is 


Once  in  300  years. 
Once  in  30  years. 
Once  in  3  years. 
Once  in  100  days. 
Once  in  10  days. 
Once  per  day, 

10  times  per  day, 
100  times  per  day. 


let  f 
let  f 
let  f 
let  f 
let  f 

1  a  -  f 


To  use  the  indices  m  the  previous  equation,  they  must  firs 
he  related  to  Impact  (I)  and  Frequency  of  Occurrence  (F) 
Such  relationships  are  expressed  in  the  following  equa 
tions  : 


fcr  Impact,  I  =  10 

(f-3)  f 

fcr  Frequency,  F  =  10  /3  =  10  /3G00 


Thus,  if  the  impact  of  an  event  is  estimated  at  $100  (i=2 

i  2 

from  Table  V)  then  1  =  10  =10  -  100.  Similarly,  if  the 

frequency  cf  occurrence  is  estimated  to  be  once  ter  day 

f  6 

(f=6)  ,  then  F  =  10  /3000  =  10  /3QG0  =  333.  3. 


Consider  the  following  practical  example,  where  the 
potential  impact  of  a  hurricane  is  $100,000  in  damage  to  a 
computer  facility,  and  the  frequency  for  a  hurricane  is  once 
in  thirty  years.  The  ALE  would  then  be  computed  as  fellows  : 

IMPACT  :  $1  00,000  (i=5 ) 

I  =  105  =  100,000 

FREQUENCY  :  1/30  years  (f=2) 

2 

F  =  1C  /3000  =  .0333 

LOSS:  I  x  F  =  100,000  x  .0333  =  3,330 


Thus,  the  ALE  resulting  from  a  hurricane  would  be  approx¬ 
imately  $3,000. 

It  is  r.o+  necessary,  howvever,  tc  compute  the  ALE  using 
these  tedicus  and  cumbersome  equations.  The  FIPS  EUB 
provides  figure  2.2  tc  facilitate  the  process.  The  ALE  for 
a  particular  event  can  then  be  found  at  the  intersection  of 
the  values  estimated  for  impact  and  frequency. 

When  all  ALEs  have  been  calculated,  the  FIPS  PUB  suggests 
that  the  approach  tc  the  remainder  of  the  task  be  done  in  an 
orderly  and  structured  manner,  in  short,  it  recommends  that 
"...the  risk  analysis  task  is  better  approached  from  the 
standpoint  cf  the  data  files,  or  applications  systems,  of 
which  there  is  a  finite  number"  [Bef.  30]. 
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Figure  2.2  Combined  Hatrix  of  i,  f,  and  ALE. 

In  terms  of  such  software  considerations,  the  publication 
discusses  three  conditions  which  might  result  if  a  threat  tc 
a  computer  system  were  realized  :  DATA  INTEGRITY  (eg. 

destruction  or  unauthorized  modifications  to  data)  ;  DATA 
CONFIDENTIALITY  (ie.  a  compromise  of  classified  data)  ;  ana 
ADP  AVAIIAEILITY  (pertaining  to  the  amount  of  time  that  a 
computer  system  can  fce  returned  to  service  after  failure)  . 

To  provide  structure  and  order  to  the  recording  cf  the 
risk  assessment  findings,  the  TIPS  ?0B  supplies  the  work¬ 
sheet  presented  as  figure  2.3  Such  a  worksheet  might 
simplify  the  record-keeping  aspect  of  the  process,  but  it  is 
only  a  suggestion  -  if  used,  it  should  oe  formatted  or 
tailored  tc  an  agency's  needs. 
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On  this  particular  worksheet,  data  files  are  listed  sepa¬ 
rately,  and  arranged  by  application.  Impact  and  frequency 
estimates  and  ALE(s)  for  each  category  of  threat  are  then 
listed  alongside  the  associated  file.  A  comments  column  is 
provided  to  allow  for  an  amplification  of  the  figures  shown. 
As  an  additional  guide  to  using  these  work  sheets,  the  FIPS 
FOB  presents  a  practical  example  (for  a  small  organization, 
of  a  complete  risk  assessment. 

The  FIFS  PUB  attempt  to  structure  the  risk  assessment 
process  adds  a  degree  of  credibility  to  the  overall  method¬ 
ology.  However,  it  is  unreasonable  to  expect  that  the  whole 
process  can  be  carried  out  as  a  "cookbook"  method.  There 
are  definite  limits  to  structuring  such  a  task,  particularly 
in  areas  such  as  identifying  and  estimating  the  threats 
against  a  facility.  In  short,  "ADP  risk  analysis  is  a  tech¬ 
nique  which  relies  heavily  cn  the  intuition,  experience  and 
technical  knowledge  cf  the  team  members"  [Ref.  30]. 

H.  CURRENT  DIRECTIVES 

Approximately  a  year  after  the  release  of  FIPS  PUE  65, 
the  NES  distributed  a  ten-page  document  entitled  "Risk 
Analysis  Standard".  The  purpose  of  this  document  was  simply 
to  standardize  the  terminology  and  concepts  behind  the  DOD 
philosophy  for  conducting  risk  assessments.  It  did  not 
supply  any  specific  guidelines  or  methodologies. 

Finally,  in  August,  19  82,  the  BON  approved  and  distri¬ 
buted  CENAVINST  5239. 1A,  a  full  and  comprehensive  manual 
describing  the  Navy’s  ADP  Security  program.  A  significant 
portion  cf  this  manual  addresses  the  approved  DON  risk 
assessment  methodology,  complete  with  forms  and  specific 
directions.  The  procedural  aspects  of  this  methodology  will 
be  presented  as  a  practical  framework  for  a  risk  assessment 
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that  cculd  be  conducted  at  the  Naval  Postgraduate  School, 
in  Chapter  4. 

This  chapter  has  described  how  the  currently-approved  CON 
methodology  has  evolved  over  the  years.  Figure  2.4  shews  a 
time  line  of  the  events  leading  up  to  the  iistr ibuticn  of 
CPNAVIN ST  5239.  1  A. 
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HI.  IN-BOOSE  VS  CONTRACTUAL  SUPPORT 


A.  GENERAL 

with  the  distribution  of  OMB  Circular  A-7 1  in  1978  came 
the  requirement  that  a  "Risk  Assessment"  (sometimes  referred 
to  as  a  "Sisk  Analysis")  be  conducted  at  each  computer 
installation  operated  by  a  federal  agency.  While  the  risk 
assessment  methodology  currently  recognized  within  the 
Department  of  Defense  is  a  manual  system,  there  are  commer¬ 
cial  software  packages  available,  notably  PANAUDIT  by 
Pansophic  Systems,  which  could  facilitate  the  "number¬ 
crunching"  aspect  of  risk  assessments.  Unfortunately,  this 
particular  software  is  only  IBM-compatible,  and  thus  has 
limited  application  tc  Navy  computer  systems. 


In  the  past  few  years,  numerous  government  directives  and 
guidelines  cn  me thodclcgies  for  conducting  risk  assessments 
have  teen  disseminated.  Many  of  these  have  resulted  from  a 
joint  effort  on  the  part  of  government  and  commercial 
industry.  In  1977,  in  an  effort  tc  perfect  a  more  concise 
methodology  that  could  be  applied  to  various  sizes  and  types 
of  computer  systems  within  the  Department  of  the  Navy, 
COMNAVDAC  let  a  contract  with  Systems  Development 
Corporation  (SDC)  to  develop  and  document  such  a  method¬ 
ology.  This  contract,  involving  contractor  support 
services,  falls  under  the  Policy/Program  Review  category 
outlined  in  NAVMATINST  4200. 50C.  The  justification  for 
contracting  cut  such  a  service  was  undoubtedly  a  matter  of 
the  expertise  held  by  the  commercial  marketplace.  The 
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result  of  the  contract  with  SDC  is  contained  in  NA VDACI NST 
5510.1,  the  Department  of  the  Navy  ADP  Security  Manual. 
While  still  in  draft  for  m,  the  distribution  of  this  manual 
will  serve  as  an  excellent  reference  for  those  Naval  agen¬ 
cies  about  to  initiate  a  risk  assessment. 

1 .  The  Need  for  Contractual  Support 

Many  government  directives  pertaining  to  ADP 
Security  provide  guidance  on  the  in-house  personnel  an 
agency  must  use  to  form  their  risk  assessment  team.  Such 
personnel  generally  include  representatives  from  ADP 
Operations  Management,  Systems  and  Applications  Programming, 
Hardware  Maintenance,  Communications  Sngineering,  Internal 
Auditing,  and  the  Security  Staff.  Since  a  comprehensive 
risk  assessment  is  a  time-consuming  process,  diverting  the 
services  of  these  individuals  from  their  normal  duties  could 
well  create  a  hardship  within  their  divisions  or  depart¬ 
ments.  This  potential  hardship  was  recognized  by  personnel 
at  NAVCAC  who  began  to  consider  the  possibilities  of 
allowing  for  contractual  support  in  conducting  risk  assess¬ 
ments.  Although  previous  directives  only  discussed 

conducting  risk  assessments  in  terms  cf  using  in-house 
personnel  resources,  NAVDACINST  5510.1  mentions  that  quali¬ 
fied  contractors  may  be  used  with  prior  approval  from 
NAVDAC. 

2.  A  Prototype  for  a  Contracted  Risk  Assessment 

In  early  1980,  personnel  at  the  Fleet  Numerical 
Oceanography  Center  (FNOC)  in  Mcnterey,  California,  began  to 
have  serious  doubts  about  their  ability  to  conduct  an 
in-hcuse  risk  assessment.  The  computer  configuration  at 
FNOC,  consisting  of  numerous  large-scale  mainframes,  commu¬ 
nications  networks  and  devices,  minicomputers,  and  peri¬ 
pherals,  was  extremely  large  and  complex.  It  would  be  very 
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difficult  to  spare  the  key  personnel  needed  or.  th-  risk 
assessment  team  from  their  everyday  duties.  Kite  tr.is  ir. 
mind,  the  ADP  Security  Officer  at  FNOC  wrote  to  N AVDAC 
asking  fer  guidance  cn  using  contractor  assistance.  NAVDAC, 
which  had  teen  giving  this  issue  a  great  deal  of  thougnt, 
decided  tc  use  FNOC  as  a  prototype  for  future  contracted 
risk  assessment  efforts.  To  this  end,  NAVDAC  offered  to 
lend  technical  assistance,  provide  liaison  with  the 
contractor  and  other  knowledgable  government  agencies,  and 
oversee  the  entire  process.  The  government  agencies  tc  be 
involved  (directly  or  indirectly)  in  the  process  are  these 
shown  in  figure  3.1,  which  was  extracted  from  NAVDACINST 
5510.  IX  [Bef.  33].  These  agencies  roughly  parallel  these 
which  play  a  key  role  in  federal  acquisition  policies  and 
procedures. 

3 .  Standar dizat icn  in  Contracted  Bisk  Assessments 

while  the  end  result  of  this  contract  effort  was  to 
be  a  completed  risk  assessment,  it  was  also  serving  as  a 
standard  against  which  future  risk  assessments  could  be 
conducted.  Thus,  as  concerns  arose  during  the  project, 
NAVDAC  documented  them  and  considered  ways  in  which  the 
process  cculd  be  enhanced  and  standardized.  This  study  will 
briefly  summarize  the  events  that  occurred  during  FNOC's 
risk  assessment,  shew  how  NAVDAC  monitored  and  controlled 
the  whcle  process,  and  describe  how  NAVDAC  has  streamlined 
the  system  tc  facilitate  contractor  support  on  any  activi¬ 
ty's  risk  assessment. 

4 •  Preliminary  Efforts 

NAVEAC's  first  priority  in  assisting  fnoc  was  tc 
gather  a  pool  of  personnel  whose  technical  expertise  would 
facilitate  the  project.  Tc  this  end,  FNOC  was  provided  a 
copy  of  NAVDACINST  5230.  1  A,  "Procedures  :cr  Requesting 


Figure  3.1  DON/ADP  security  Organizational  Relationships 


Services  frcra  Navy  Regional  Data  Automation  Centers 
(NARDACs) M.  FNOC* s  task  was  to  generate  a  letter  requesting 
technical  support  services  from  NARDAC,  San  Francisco. 
Included  in  this  letter  was  information  pertaining  to 


project  title,  requesting  command,  type  of  request,  objec¬ 
tives,  security  classif ication,  and  funding.  Identifying 
the  source  of  the  funding  is  an  important  consideration  in 
requesting  NARDAC  services.  ‘'Commencing  in  fiscal  year  1982 
all  Navy  customers  of  a  NARDAC,  except  Navy  industrial  Fund 
Activities,  will  be  supported  on  an  entirely  mission  funded 
basis.. . Deprogrammed  costs  which  cannot  be  accommodated  will 
be  subject  of  discussion  between  the  NARDAC  and  the  customer 
to  determine  if  other  means  of  funding  are  available" 
[Ref.  34].  In  this  situation,  FNOC  had  budgeted  S100K  for 
the  risk  assessment  project,  and  the  NARDAC  had  no  funds 
available.  It  was  thus  determined  that  FNOC  would  remit  the 
$1Q0K  to  the  NARDAC,  who  along  with  NAVDAC,  would  use  the 
funds  to  cover  the  costs  of  the  government's  technical 
support  personnel  and  the  contractor's  fees. 

Cnee  the  method  of  funding  had  been  determined, 
NAVDAC  sent  technical  experts  from  the  NARDAC,  NAVELEX,  and 
NESEA  (Naval  Electronics  Systems  Engineering  Activity)  to 
FNOC  tc  discuss  the  program  with  ADP  Security  personnel. 
These  personnel  outlined  the  project  and  generated  a  docu¬ 
ment  cn  FNCC*  s  computer  assets  for  use  by  the  contractor. 
NAVDAC,  in  the  meantime,  was  using  inputs  from  this  group  to 
generate  a  plan  of  action  and  milestones  that  the  contractor 
would  be  expected  to  follow. 

5 .  lue  Contract 

NAVDAC  handled  all  the  requirements  for  negotiating 
and  awarding  the  contract.  The  details,  however,  or.  the 
negotiations,  evaluation,  selection,  and  award  were  not 
available  tc  the  authors.  After  the  negotiations  had  been 
completed,  the  contract  was  awarded  to  Systems  Development 
Corporation  (SDC). 


Ey  the  time  the  SDC  personnel  arrived  at  FNOC,  they 
had  been  in  constant  touch  with  the  project  manger  at 
NAVDAC,  and  were  well  aware  of  the  tasks  expected  cf  them. 
By  interviewing  personnel  from  all  areas  of  FNOC*s  organiza¬ 
tional  components,  reviewing  computer  configuration  sche¬ 
matics  and  documentation,  penetrating  computer  security 
vulnerabilities  and  merging  them  with  potential  threats, 
they  were  able  to  assess  FNOC's  security  posture  and  produce 
the  required  documentation  and  Annual  Loss  Expectancy  (ALE) 
figures. 

6.  Future  Risk  ftssessm ent  Contract s 

Since  a  risk  assessment  contract  will  call  for  a 
study  or  analysis  of  the  security  aspects  cf  an  existing 
computer  system,  it  will  have  to  adhere  to  the  requirements 
of  NAVMA1INST  4200. 50C  which  addresses  contractor  support 
services.  If  FNOC^  contract  was  any  indication,  future 
risk  assessment  contracts  will  undoubtedly  exceed  $50k,  and 
thus  will  require  legal  review  and  approval  by  "...a  level 
no  lcwer  than  Flag  or  General  Officer  or  individuals  in  the 
Senior  Executive  Service  (SES)  "  [fief.  31]. 

In  an  effort  tc  make  FNOC  and  its  parent  command. 
Commander,  Naval  Oceanography  Command  (CNOC)  ,  more  autono¬ 
mous  ir.  contracting  for  future  ADF  security-related 
services,  NAVBAC  recently  drafted  a  letter  in  which  the 
subject  line  reads,  ’'Automated  Data  Processing  (ADP) 
Security  Accreditation  and  Contractor  Assistance" .  This 
document  will  be  invaluable  to  any  Naval  activity  consid¬ 
ering  contract  support  in  completing  a  risk  assessment. 
Although  the  information  will  not  be  afforded  general 
distribution,  NAVDAC  is  amenable  to  providing  it  when 
requested  by  a  Navy  activity.  The  several  enclosures  to  the 
document  constitute  sample  ADP  security  contracting  docu- 


47 


ments,  which  as  NAVDAC  mentions,  mast  be  tailored  no 
specific  tasking  requirements  and  coordinated  with  the  local 
Navy  Begicnal  Contracting  Center.  NAVDAC's  purpose  in  this 
effort  is  "...an  attempt  to  assure  that  Navy  activities 
receive  quality  contractor  ADP  security  reports  and  products 
for  dollars  invested"  [Ref.  32]. 

Among  the  enclosures  is  a  sample  statement  of  work 
which  may  be  tailored  and  included  as  part  of  an  activity's 
Request  for  Proposal  (RFP)  ,  or  in  NAVDAC  terms.  Task  Order 
or  Task  Bequest.  The  sample  not  only  addresses  risk  assess¬ 
ments,  tut  also  includes  other  ADP  security  areas  which  may 
be  candidates  for  contractor  assistance  :  Risk  Assessment 

Planning,  Contingency  Plan  Testing,  and  Security  Training. 
It  is  the  jcb  of  an  activity's  ADP  Security  officer  to  write 
a  task  request  based  on  the  statement  of  work,  describing 
the  specific  area  of  the  work  required.  NAVDAC' s  sample 
work  statement  has  specific  guidelines  on  the  necessary 
wording,  including  a  list  of  military  publications  to  which 
the  contractor  must  be  responsive,  and  a  list  of  required 
deliverables  such  as  summary  progress  reports,  schedule  cf 
performance,  and  contract  financial  progress  reports.  The 
sample  work  statement  also  includes  an  option  tc  extend  the 
term  cf  the  statement  of  work.  This  will  be  renewable  at 
prices  stated  by  the  contractor  and  at  the  option  cf  the 
government.  In  addition,  NAVDAC  provides  guidance  on  the 
Government-Furnished  Equipment  and  documentation  tha4-  an 
activity  should  be  prepared  to  provide  the  contractor. 
Other  documents  NA7CAC  has  included  as  samples  are  :  the 
Contract  Security  Classification  Specification,  detailing 
the  security  considerations  and  access  requirements; 
Ccntractcr  Personnel  Qualifications  Statement,  describing 
the  minimum  gualif  ication  s  expected  of  the  contractor 
personnel  assigned  tc  the  project;  Personal  vs  Nor.psrsonal 


C*: 


Services  Questionnaire,  a  document  used  by  the  contract  ing 
officer  to  determine  whether  cr  net  the  solicited  service  is 
nonperscnal;  and  the  Contract  Data  Requirements  List,  which 
describes  the  required  deliverables.  These  are  all  standard 
requirements  for  an  RFP,  but  they  have  been  uniquely 
tailored  for  a  Risk  assessment  application. 

As  cf  28  July  1982,  NAVDAC  had  approved  six  organi¬ 
zations  to  he  included  on  the  Bidder's  Mailing  List.  These 
organizations  and  their  qualifications  are  shown  in  figure 
3.2.  at  the  time  of  this  writing,  three  were  qualified  to 
conduct  risk  assessments,  but  only  two  of  these  had  DON 
approval.  Two  of  the  organizations  listed  were  small  busi¬ 
nesses. 

Each  of  these  vendors  will  be  notified  of  a  task 
request  by  the  Ccntract  Administration  Office  (CAO) . 
Vendors  are  required  to  pick  up  the  task  request  within  a 
week  cf  nctification.  NAVDAC  refers  to  vendor  responses  as 
"Task  Order  Proposals”  (TOPs).  As  is  the  case  with  standard 
RFPs,  these  are  due  at  a  specified  time  and  date. 
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7.  g  icccsal  Evaluations  and  Sal  act  ion 

Information  required  in  a  TOP  for  a  risk  assessment 
includas  "the  number  cf  man-hours  by  skill  category  by  task 
and  subtask,  milestone  dates,  travel  costs,  proposed  pricing 
arrangements,  personnel  resumes,  and  technical  approach" 
[Ref.  32].  The  function  cf  the  activity’s  technical  evalua¬ 
tion  board,  chaired  by  the  ADP  Security  Officer,  who  is 
generally  assigned  as  project  manager,  will  be  to  evaluate 
these  factors. 

NAVEAC  stresses  the  importance  of  contractor 
personnel  qualifications  in  evaluating  and  selecting  the 
contractor.  Particular  emphasis  is  placed  on  personnel 
weighting  factors,  with  the  result  that  factors  other  than 
cost  may  weigh  heavily  in  the  selection  of  one  contractor 
over  another.  The  list  of  qualifications  for  contractor 
personnel  are  quite  comprehensive.  Particularly  important, 
especially  for  the  lead  person  assigned  by  the  contractor, 
is  experience  in  computer  center  operations,  ADP  Risk 
Assessment  methods,  system  software  generation,  computer 
security,  telecommunications  security,  and  computer  hardware 
and  interconnections.  A  proposal  which  describes  personnel 
with  less  than  these  qualifications  may  be  considered  "non- 
responsive".  In  order  to  promote  continuity  ana  stability 
throughout  the  length  cf  the  project,  NAVDAC  also  encourages 
considering  the  contractor’s  response  to  the  requirement 
that  "50  percent  of  original  contractor  personnel  arriving 
on  a  Navy  site  to  perform  a  risk  assessment  will  remain  on 
site  for  the  duration  of  the  contract"  [Ref.  32], 

Evaluation  of  cost  factors  will  generally  be  handled 
by  the  Procuring  Contracting  Officer  of  the  Navy  Regional 
Contracting  Center.  This  will  exclude  consideration  of  the 
cost  cf  preparing  the  TOP,  which,  as  is  the  case  with 
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conventional  RFPs,  is  done  at  the  expanse  of  the  c crtractor. 
However,  those  prices  which  will  be  recognized  include  "ell 
direct  labor,  overhead,  general  and  administrative  expenses, 
plus  an  amount  for  profit"  [Bef.  32].  In  this  regard,  most 
risk  assessment  contracts  will  probably  be  cf  the 
Cost- plus-fixed- fee  type.  3ased  on  NAVDAC's  general 

guidance  for  evaluation  factors  and  weightings,  a  proposed 
Internal  Sccre  sheet  for  any  activity's  TOP  evaluation  is 
included  as  figure  3.3  .  The  reasoning  for  the  discrepancy 
between  experience  and  past  performance  is  as  fellows  : 
experience  in  all  areas  listed  is  crucial,  and  while  past 
performance  on  related  contracts  would  certainly  be  a 
desired  feature  in  a  contractor,  chances  are  that  few  will 
have  dealt  directly  with  risk  assessments  (considering  that 
they  are  a  relatively  new  requirement).  Price  factors 
should  constitute  about  20  percent  cf  the  total  weighting. 
After  the  contract  administrator  has  completed  the  negotia¬ 
tions,  the  selection  is  made,  and  "a  finalized  Task  Order 
will  be  executed  by  the  contractor  and  the  contracting 
officer"  (Bef.  32]. 

B.  CONCLUSIONS 

NAVCAC's  recognition  of  the  need  for  allowing  contractor 
assistance  in  conducting  c  cm  purer  risk  assessments  is  both 
admirable  and  realistic.  Sven  if  an  activity  cculd  spare 
the  personnel  necessary  to  conduct  a  risk  assessment,  there 
would  undoubtedly  be  a  lack  of  expertise  in  the  necessary 
policies  and  procedures.  At  this  stage  of  the  game,  where  a 
risk  assessment  is  still  a  relatively  new  and  complex  pheno¬ 
menon,  few  people  understand  what  it  is,  let  alor.e  hew  to 
conduct  an  assessment.  (This  will  undoubtedly  change, 
however,  as  NAVDAC  places  more  and  more  emphasis  on  ADP 
Security  training)  . 


52 


laiacaal  sssta  ifcasi 


1.  Technical  Approach  —  Height  30  points 

a. )  Understanding  of  Task 

1. )  Bisk  Asssssamt  0-4  _ 

2. )  Hethcdology  0-4  _ 

b. )  Besponsivaness  to  specifications 

in  Task  Baque3t  0-15  _ 

c. (  Appropriateness  of  approach 

1. )  Activity's  environien  t/ops  0-3  __ 

2. )  Activity's  coaputer  configuration  0-2  ___ 

3. )  Don-approved  risk  asseasaent 

reqoiraaents  0-2  ___ 

2.  Experience  --  weight  30  paints 

A. )  Coaputer  Center  operations  0-3  _ 

B. )  AOP  Bisk  Assessaent  (let hods  0-7  ___ 

C. )  Systaa  Software  Generation  0-3  _ 

D. )  coaputer  Security  0-6  __ . 

E. )  Telecoaaunications  Security  0-3  ___ 

F. )  Coaputer  Hardware  and  Intarconnections  0-3  __ 

G. )  Clearance  coaaensurate  with  the  highest 

level  contained  in  the  systea  0-5  __ 

3.  Past  Per  for  nance  —  weight  15  points 

A.)  Conducting  Risk  Assessaents  0-5  ___ 

8.)  Perforaing  AOP  Security-related  projects  0-10 _ 

a.  sanageeent  —  weight  20  points  0-20  __ 

5.  Location  --  weight  5  points  0-5  _ 

(with  the  understanding  that  50*  of  the  original  contractor 
personnel  reaain  on  site  for  the  duration  of  the  contract). 

OFPEBOB  : _ 

ETALOATOB  : _ 


Figure  3.3  Contractor  Evaluation  Score  Sheet. 
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While  specific  details  and  samples  of  contract  documents 
are  available  to  any  activity  re  guesting  them,  UAVCAC 
encourages  tailoring  them  to  the  activity's  needs.  As  top 
management,  security  personnel,  and  computer  specialists 
become  mere  educated  in  the  risk  assessment  phenomenon,  the 
need  for  such  specific  guidance  will  dwindle.  in  the  mean¬ 
time,  government  resources  will  be  saved  by  avoiding  the 
possibility  of  mismanagement  of  contracting  for  computer 
risk  ‘.ssessment s. 
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IV.  A  FEAMEVO  RK  FOB  CONDOCTIHG  A  BISK  ASSESSMENT  AT  NPGS 

The  Eepartmsrt  of  the  Navy  Automatic  Data  Processing 
Security  Program  was  recently  promulgate!  by 
OPN AVINST . 5239 .  1A  on  August  3,  .982.  The  instruction 

provides  policy  and  guidance  to  commanding  officers 
concerning  the  establishment  of  local  automatic  data 

processing  (ADP)  security  programs.  Each  command's  program 
should  be  designed  with  the  goal  of  achieving  accreditation 
by  the  appropriate  designated  approving  authority  (DAA)  .  Ir. 
particular,  each  activity  must  develop  an  activity  ADP 
security  plan  (AADPSP).  This  plan  must  be  approved  by  the 
Commander,  Naval  Data  Automation  Command  (COMNAVDAC)  .  The 
AADPSE  should  document  current  security  environment,  estab¬ 
lish  program  objectives,  and  outline  a  plan  of  action  ana 
milestones  (POAM)  for  security  program  implementation.  An 
item  that  will  be  included  in  the  POAM  is  the  completion  of 
a  risk  assessmemt.  A  risk  assessment  may  be  conducted  inter¬ 
nally  if  an  ADP  activity  has  the  necessary  expertise 
Commercial  assistance  is  available  to  conduct  a  risk  assess¬ 
ment.  CCMNAVDAC  maintains  a  list  of  authorized  contractors 
and  retains  approval  authority  for  contractor  selection. 

This  chapter  provides  a  framework  for  conducting  a  risk 
assessment  at  the  Naval  Postgraduate  School.  A  framework,  in 
the  absence  cf  theory,  is  helpful  in  organizing  a  complex 
subject,  identifying  the  relationships  between  the  parts  and 
revealing  the  areas  in  which  further  development  may  be 
required  £Bef.  35]*  A  risk  assessment  at  a  naval  activity 
must  be  governed,  of  course,  by  OPNAVINST.  5239.  1  A.  However, 
this  instruction  is  very  broad  in  scope  and  covers  the 
entire  AEt  security  spectrum.  It  should  be  helpful  to  have 
the  necessary  steps  fcr  a  risk  assessment  ,  applied  tc  the 
Naval  Postgraduate  School,  presented  in  this  framework. 
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A  risk  assessment  involves  a  detailed  examination  cf  all 
the  aspects  cf  a  computer  system:  hardware,  software,  data, 
procedures,  etc.  The  use  of  these  assets,  that  is,  the  use 
of  the  computer  systems  at  the  Naval  Postgraduate  School, 
including  the  IBM  3033AP  system  in  the  W.C.  Church  Computer 
Center,  various  mini  and  microcomputers  in  Spanagsl  Hall, 
and  independent  units  obtained  under  grant  by  several  prof¬ 
essors,  spans  virtually  all  departments  and  includes 
faculty,  students,  and  military  and  civilian  staff.  This 
fact  implies  that  a  significant  amount  of  cooperation 
between  different  organizations  will  be  required  to  success¬ 
fully  complete  a  risk  assessment.  This  endeavor  requires 
command  attention  at  upper  levels  to  impress  upon  all 
concerned  the  importance  with  which  the  command  views  a 
subject  cf  this  nature.  iiith  this  understanding,  a  project 
cf  this  magnitude  should  produce  meaningful  results  which 
will  serve  several  purposes: 

1)  Enable  the  Naval  Postgraduate  School  to  proceed 
successfully  along  the  path  to  ADP  security 
accreditation. 

2)  Provide  documentation  stating  the  currant  conditicn 
of  security  with  respect  to  the  computer  systems 

at  the  Naval  Postgraduate  School. 

3)  Provide  a  reference  for  quantitatively  evaluating 
security  countermeasures. 

4)  Provide  a  platform  from  which  improvements  in 
command  security  posture  can  be  built. 

A.  INITIAL  STEPS:  PERSONNEL  SELECTION  AND  SECURITY  SURVEY 

The  initial  step  in  undertaking  this  project  is  to  iden¬ 
tify  the  personnel  who  will  participate  as  members  of  the 
risk  assessment  team.  Expertise  from  various  disciplines 
such  as  computer  science,  manaqement,  and  administrative 


science  will  be  required.  Personnel  selection  is  a  very 
delicate  subject  in  the  commercial  environment.  Dcnn  Parker 
of  the  Stanford  Research  Institute  (SRI),  at  the  1977 
National  Computer  Conference,  criticized  the  concept  of  a 
risk  assessment  team  made  up  of  key  company  personnel.  A 
team  approach  gives  a  relatively  large  number  of  employees  a 
virtual  inventory  of  data  processing  vulnerabilities.  If 
may  be  prudent  to  have  risk  assessment  team  members  partici¬ 
pate  in  detailed  analyses  only  on  a  need-to-kncw  basis. 
[Ref.  40]  However,  this  situation  will  not  pose  a  problem  at 
the  Naval  Postgraduate  School.  Siven  the  relatively  tran¬ 
sient  nature  of  students  and  staff  at  this  institution,  the 
following  recommendations  for  staffing  this  project  are 
proposed.  The  position  of  project  manager  should  be 
assigned  to  the  ADP  security  officer.  The  tasks  which  this 
position  entails  are  quite  consistent  with  the  duties  of  the 
ADP  security  officer.  Additionally,  the  participation  of 
students  frcm  the  Computer  Systems  Management  and  the 
Computer  Science  curricula  should  be  solicited.  The 
majority  or  the  work  required  in  this  project  cculd  be 
completed  by  students.  The  risk  assessment  may  serve  as  a 
thesis  project  for  several  teams  of  interested  students. 
Faculty  members  of  the  Computer  Council  could  function  in 
the  role  of  thesis  advisors  while  maintaining  an  active 
interest  in  the  risk  assessment  process.  The  project  could 
be  broken  into  three  distinct  phases.  Students  partici¬ 
pating  in  these  phases  would  build  drrectly  upon  the  work 
accomplished  by  earlier  students.  A  proposed  phased  organi¬ 
zation  might  be: 

1)  Security  Survey,  Asset  Identification  and  Valuation 
Phase 

2)  Threat  and  Vulnerability  Evaluation  Phase 

3)  Computation  of  Annual  Loss  Expectancy  and  Evaluation 
and  Selection  of  Additional  Countermeasures  Phase 


Tha  formal  assignment  of  personnel  to  the  Risk 
Assessment  Team  is  accomplished  by  tha  issuance  of  the  Sisk 
Assessment  Team  Charter.  The  charter  is  generated  by  -.he 
command  itself  and  identifies  those  personnel  who  compose 
the  team.  Since  students  will  be  participating  in  this 
endeavor,  periodic  updates  to  this  document  will  be 
required.  The  document  lists  the  objectives  of  the  team  and 
details  the  authority  and  responsibility  of  each  person. 
The  charter  also  states  the  products  which  tha  team  is 
expected  to  produce. 

The  next  step  in  the  overall  process  is  to  conduct  an 
ADP  security  survey.  A  sampla  survey  is  listed  in  the  ADP 
Security  manual  [Ref.  36].  An  item  which  will  be  needed  to 
ensure  that  the  survey  is  complete  is  a  listing  of  all  ADP 
equipment  located  at  the  Naval  Postgraduate  School.  The 
survey  should  encompass  all  equipment  so  that  its  results 
can  be  interpreted  with  seme  degree  of  confidence.  The 
results  provide  an  indication  of  the  current  security  situa¬ 
tion  and  also  may  show  how  much  effort  will  be  required  tc 
conduct  the  risk  assessment.  iz  should  be  noted  that  a 
complete  and  accurate  listing  of  all  equipment  is  crucial  tc 
the  success  of  the  overall  assessment.  Failure  to  include 
certain  equipment  may  invalidate  any  assessments  made  on 
ether  equipment  affected  by  missing  items.  The  major  compo¬ 
nents  of  the  I a»  3033A?  system  are  listed  in  an  NPGS  publi¬ 
cation,  ’'Introduction  to  the  Church  Computer  Center”.  Of 

course,  this  information  should  be  verified  prior  to  use  in 

this  endeavor. 

The  vast  majority  of  the  users  are  not  working  with 

high-value  data,  but  rather  with  routine,  academically 

oriented  material.  No  classified  data  is  supposed  to  be 
stored  on  the  IBM  3033AP  system.  Additionally,  most  of  the 
processing  done  at  the  Church  Computer  Center  is  not  in 
support  of  fleet  operations.  The  results  of  the  survey 


indicate  some  directions  for  the  risk  assessment  tc  pursue. 
The  formal  results  of  the  survey  should  be  compiled  and 
submitted  as  an  appendix  to  the  risk  assessment  document. 

The  results  of  the  survey  also  impact  upon  the  risk 
methodology  selected.  As  the  ADP  Security  manual  stares, 
'•the  decision  (concerning  which  merhodology  tc  use)  should 
be  based  on  the  complexity  of  r’ne  ADP  environment  The 
complexity  is  governed  by  the  lavel  of  dara  processed, 
security  mode  of  operation,  ADP  sysrem  conf iguraricn  and 
location,  and  the  criticality  of  the  mission.”  [Bef.  37] 
There  are  two  methodologies  available.  The  most  common 
methodology  for  ADP  activities  is  listed  in  the  Security 
manual  as  Methodolgy  1.  This  methodology  appears  tc  be 
suitable  for  a  risk  assessment  at  the  Naval  Postgraduate 
School.  Methodology  1  is  the  standard  methodology  used  in 
most  ADP  environments  and  provides  for  suitable  interaction 
between  threats  and  losses.  The  risk  assessment  conducted 
according  to  methodology  1  can  be  divided  into  several 
phases  as  shown  in  figure  4.1.  As  previously  mentioned, 
these  phases  cculd  quite  conveniently  be  assigned  to 
students  as  thesis  projects.  The  successful  completion  of 
each  phase  is  well  within  the  capabilities  of  interested 
students . 


B.  ASSET  IDENTIFICATION  AND  V ALUATION 


The  next  phase  in  this  process  consists  of  asset  identi¬ 


fication  and  valuation. 


Some  crucial  items  of  information 


are  needed  to  properly  complete  this  phase.  As  previously 

mentioned,  a  complete,  up-to  date  list  of  all  computer 

system  assets  is  required.  The  Computer  Council  is  tasked 
with  maintaining  an  inventory  of  all  hardware  assets 

[Bef.  38].  They  should  be  able  to  provide  the  necessary 

information  in  this  area.  Completeness  and  accuracy  are  the 
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Figure  4.1  Major  Steps  of  Method  I  Bisk  Assessment. 

keys  to  the  success  of  the  risk  assessment.  Otherwise,  the 
possibility  exists  that  some  piece  of  AD?  equipment  not 
listed,  and  so  not  considered  in  the  risk  assessment,  may 
somehow  interact  with  equipment  that  is  considered.  The 
threat  and  the  associated  loss  may  invalidate  the  assess¬ 
ments  made  previously  on  related  equipment. 

The  other  elements  crucial  to  this  phase  are  the  impact 
value  ratines.  The  risk  assessment  team  will  determine  the 
impact  value  ratings.  The  ADP  Security  manual  gives  seme 
general  guidance  for  assigning  these  values.  Since  the 
major  purpose  of  a  risk  assessment  is  to  provide  a  quantita¬ 
tive  base  for  evaluating  the  cost-effectiveness  of  counter¬ 
measures,  the  importance  of  these  values  cannot  be 
overstated.  Primary  input  for  the  values  associated  with 
hardware  and  software  can  probably  be  provided  by  the 
computer  center  staff. 
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There  are  four  types  cf  impacts  for  which  each  asset 
must  fce  evaluated.  These  impacts  are: 

1)  Modification 

2)  Destruction 

3)  Disclosure 

4)  Denial  of  service 

The  ADP  Security  manual  provides  a  concise  definition  of 
these  impacts.  Each  asset  must  be  evaluated  with  respect  to 
these  items.  If  an  impact  affects  an  asset,  then  a  monetary 
value  reflecting  that  effect  should  be  assigned.  The  impact 
value  rating  is  associated  with  the  monetary  value.  This 
stage  will  require  close  coordination  between  the  students 
evaluating  the  assets  and  those  members  cf  the  team  who 
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Figure  4.2  Sensitive  Data  Value  Guidelines. 


determine  the  asset  impact  value  ratings.  The  ADP  Security 
Manual  provides  guidelines  for  the  impact  of  disclosure  of 
sensitive  data.  These  values  are  listed  in  figure  4.2. 

There  are  standard  forms  which  should  be  used  to  record 


the  asset  impact  and  valuation  studies.  The  appropriate 
form  for  this  phase  is  designated  OPNAV  5239/7.  An  example 
cf  this  form  is  provided  in  Appendix  I. 


C.  THREAT  &ND  V OINSBAfll  LIT  I  EVALUATION  PHASE 

Tfce  next  phase  in  the  risk  assessment  process  is  the 
threat  and  vulnerability  evaluation.  According  to  -he  meth¬ 
odology,  all  threats  must  be  evaluated  to  estimate  how  often 
a  "successful”  attack  may  occur.  By  definition,  a 
"successful"  attack  is  one  that  results  in  a  definite 
adverse  impact  on  the  activity. 

This  phase  will  also  require  a  great  deal  of  communica¬ 
tion  between  the  members  of  the  risk  assessment  team  and  the 
staff  of  the  computer  center.  For  certain  threats  such  as 
power  outages,  the  frequency  rating  could  be  determined  by 
examining  historical  data.  However,  input  from  the  computer 
center  staff  may  prove  valuable  when  attempting  to  determine 
frequency  ratings  for  threats  which  are  highly  technical, 
such  as  errors  in  the  operating  system  software.  Each 
threat  must  be  evaluated  with  respect  to  the  same  four 
impact  areas  as  the  assets,  that  is,  modification,  destruc¬ 
tion,  disclosure,  and  denial  of  service.  For  certain 
threats  which  have  never,  and  hopefully  will  never,  occur 
there  may  be  some  difficulty  in  assigning  threat  frequen¬ 
cies.  There  is  no  sound  statistical  base  for  assigning 
probabilities  to  human  behavior  problems.  One  method  to 
approach  this  problem  is  to  use  the  Delphi  technique.  This 
methed  involves  having  different  individuals  evaluate  a 
particular  probability  several  times  to  reach  a  consensus. 
This  technique  should  provide  a  probability  estimate  which 
may  offset  the  lack  cf  a  human  experience  base.  [Ref.  41] 

A  great  deal  of  time  and  effort  will  be  required  during 
this  phase.  The  more  imagination  which  is  applied  tc  devel¬ 
oping  the  threats  and  their  potential  adverse  effects,  the 
more  accurate  the  final  risk  assessment  will  be.  As  a 
result,  the  product  will  serve  its  purpose  and  hopefully 
enhance  ACP  security. 
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The  ADF  Security  manual  provides  a  list 


se  vs  ral 


example  threats.  However,  this  list  is  certainly  net  all 
inclusive.  Threats  which  ars  particular  to  the  Naval 


Postgraduate  School  computer  system,  such  as  the  vulner¬ 
ability  cf  the  back-up  power  supplies  and  its  location  on 


the  flight  paths  of  the  Monterey  County  Municipal  Airport 


must  be  considered  .  The  scope  of  this  risk  assessment  is 
all-enccmpassing.  Much  imaginative  thinking  will  be 
required  during  this  phase  of  the  undertaking,  however,  the 
payoff  in  terms  cf  usable  output  should  make  it  worthwhile. 
The  threats  should  be  defined  to  minimize  overlap.  The 
reason  for  this  concern  is  generated  by  the  method  of 
computing  the  annual  loss  expectancy,  which  will  be 
addressed  in  the  next  step  of  this  phase. 


The  threat  and  vulnerability  evaluations  should  also  be 


documented  on  standard  forms.  An  example  of  this  form. 


OPNAV  5239/9,  is  enclosed  in  Appendix  I.  The  information 
that  should  be  described  for  each  threat  includes  a  general 
narrative  about  the  threat.  Examples  of  the  threat  should 
be  listed  and  any  counter  measures  which  are  currently  in 
effect  should  be  noted.  Also,  any  unique  circumstances  cf 
the  command  which  might  contribute  to  the  threat  should  be 
discussed. 

As  with  :ha  previous  phase,  this  portion  of  the  risk 
assessment  could  also  serve  as  a  thesis  project.  Again, 
however,  it  must  be  emphasized  that  close  coordination 
between  the  risk  assessment  team  and  the  computer  center 


staff  is  necessary  tc  ensure  that  every  potential  threat  is 


considered  and  that  every  frequency  rating  represents  a 
realistic  estimate. 

After  completing  the  asset  valuation  and  threat  evalua¬ 
tion  phases,  the  next  step  is  to  compute  the  annual  less 
expectancy  values  (AIE) .  This  step  provides  the  quantita¬ 
tive  results  which  will  be  used  tc  evaluate  adiititonal 


security  measures.  The  AD?  Security  manual  describes  a 
mechanical,  fairly  straight-forward  procedure  to  determine 
these  figures.  The  impact  dollar  value  ratings  and  the 
successful  attack  frequency  ratings  interact  to  produce  an 
annual  loss  expectancy  figure  for  each  of  the  four  impact 
areas.  The  individual  ALE  values  for  each  asset  in  an 
impact  area  and  the  individual  ALE  values  for  each  threat  in 
an  impact  area  should  be  added  to  produce  a  total  ALE  value 
for  each  respective  impact  area.  Summing  the  ALE  values 
ever  the  four  different  impact  areas  results  in  the  total 
ALE  value  for  the  system. 

As  stated  in  the  AD?  Security  manual,  the  ALE  "repre¬ 
sents  a  quantitative  estimate  of  the  potential  average 
yearly  financial  less  resulting  from  the  modification, 
destruction,  disclosure  of  data,  or  denial  of  services 
because  of  existing  vulnerabilities  which  may  permrt  identi¬ 
fied  threats  to  be  realized."  [8ef.  39]  One  car.  see  that 
the  types  of  results  which  are  derived,  namely,  quantitative 
figures  cr  annual  less  expectancy,  are  based  totally  upon 
the  estimates  made  in  earlier  phases.  For  the  ALE  figures 
to  be  meaningful,  it  is  clear  that  a  great  deal  of  care  must 
be  taken  tc  develop  reasonable  asset  valuations  and  impact 
area  dollar  ratings.  Also,  tne  threat  evaluation  and 
successful  attack  frequency  must  be  consistent  and  net  exag¬ 
gerate  any  particular  area  without  justification. 

D.  EVALUATION  AND  SEIECTION  OP  ADDITIONAL  COONTERHE ASDBES 

After  the  annual  loss  expectancy  values  have  been  calcu¬ 
lated,  the  evaluation  of  additional  countermeasures  can  be 
conducted.  The  procedure  involves  determining  whether  the 
additional  countermeaures  would  benefit  the  overall  security 
posture  and  result  in  a  decrease  in  the  annual  loss  expec¬ 
tancy  value.  Cost-effectiveness  is  the  criteria  for 
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decision-making  when  considering  any  additional  countermea¬ 
sures.  Essentially,  every  countermeasure  must  be  evaluated 
to  determine  if  the  reduction  in  the  ALE  is  greater  than  the 
cost  of  installation  and  implementation.  Countermeasures 
may  be  directed  against  specific  threats.  Some  software 
countermeasures  include  the  establishing  of  audit  trails, 
the  use  cf  unique  pa ssvo rd/authentication  processes,  and  the 
imposition  cf  some  type  of  residue  control  to  clear  sensi¬ 
tive  information  which  the  operating  system  allows  tc  remain 
in  resource  sharing  storage.  Seme  hardware  countermeasures 
include  the  emplcymentof  protection  state  variables,  memory 
protection  mechanisms,  and  the  use  of  interruption  resistant 
power  supplies.  These  are  merely  a  few  examples  of  counter¬ 
measures  which  can  be  utilized  to  improve  security.  They 
may  be  such  that  the  successful  frequency  attack  ratings  in 
several  impact  areas  are  affected. 

The  procedure  for  evaluating  additional  countermeasures 
consists  of  six  steps: 

1)  countermeasures  which  can  reduce  the  vulnerabilities 
cf  those  assets  which  currently  have  the  higher  annual 
loss  expectancy  values  should  be  considered  first. 

2)  The  vulnerabilities  which  would  be  reduced  or  elimi¬ 
nated  by  implementing  additional  countermeasures  should 
be  identified. 

3)  Assuming  that  the  countermeasure  is  implemented,  the 
projected  successful  attack  frequency  ratings  for  each 
area  should  be  listed. 

4)  A  projected  ALE  for  each  threat  affected  by  the 
countermeasure  should  be  calculated  by  impact  area. 

5)  The  projected  ALE  should  be  subtracted  from  the 
current  ALE  to  show  the  savings  possible  by  imple¬ 
menting  the  proposed  countermeasure. 

6}  The  ALE  savings  in  each  impact  area  should  be  summed 
and  then  divided  by  the  annual  cost  of  the  countermea¬ 
sure  tc  get  the  Betura -on-Investment  (ROI)  .  [Ref.  42] 
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Again,  there  is  a  specific  fora  provided  to  perforin  these 
calculations.  An  example  of  ohis  form,  OPNAV  5239/10,  is 
given  in  Appendix  I. 

The  Eeturn-cn-Inves  tment  figure  is  important  in  the 
selection  of  which  additional  countermeasure  to  iirplement. 
This  selection  process  occurs  in  an  incremental  fashion.  As 
countermeasures  are  implemented,  they  affect  the  overall 
security  posture  of  the  entire  computer  center.  This  effect 
is  realized  in  a  different  ALE  value.  Since  changes  in  the 
ALE  will  cause  a  corresponding  change  in  the  HOI  for  a 
particular  countermeasure,  the  countermeasures  must  be 
considered  singly. 

The  countermeasure  with  the  highest  HOI  is  considered 
first.  Then,  the  countermeasure  with  the  next  higher  HOI  is 
evaluated  with  the  new  ALE  resulting  from  implementation  of 
the  previous  countermeasure.  This  procedure  is  continued  as 
long  as  the  respective  HOI  remains  greater  than  one.  The 
countermeasures  with  HOI*s  greater  than  one  may  be  ranked 
according  tc  their  respective  values.  A  plan  to  implement 
these  countermeasures,  within  budgetary  limitations,  may 
then  be  determined. 

The  situation  may  occur  where  higher  authority  directs 
that  certain  countermeasures  be  implemented.  In  that  case, 
these  countermeasures  may  take  priority  for  implementation 
regardless  cf  their  SCI. 


?.  AUTOMATED  VS.  MANUAL  BISK  ASSESSMENT  SYSTEMS 

A.  GFNEEAL 

At  this  time,  no  automated  or  computerized  risk  assess¬ 
ment  methodology  has  been  approved  for  use  by  agencies  of 
the  Federal  Government.  This  is  no  reflection  on  the 
Government's  lack  of  interest  or  distrust  in  the  product;  it 
is  more  a  matter  of  an  extremely  limited  market  -  there  are 
less  than  a  handful  of  risk  assessment  software  packages 
currently  available. 

One  of  the  few  companies  in  private  industry  involved  in 
developing  risk  assessment  software  is  Pansophic  Systems, 
Inc.,  based  in  Oak  Erook,  Illinois.  Among  the  software 
security  products  the  company  offers  are  :  Panaudit,  a  tool 
that  can  be  used  fcr  ADP,  financial,  and  statistical 
auditing  cf  computer  systems;  Panexec,  which  can  be  used  fcr 
auditing,  control,  backup,  and  recovery  measures;  and 
Panrisk,  an  automated  risk  assessment  system  for  management 
planning.  Advertisements  for  Panrisk  boast  that  it  is 
"...the  first  system  ever  to  show  where  to  direct  your 
computer  security  efforts  with  quantifiable  certainty" 
[Hef.  43]. 

Although  the  Panrisk  system  works  under  the  same  basic 
framework  as  the  manual  methods  advocated  within  the  DOC,  it 
has  a  major  drawback  that  greatly  limits  its  usefulness  and 
applicability  to  government  computer  facilities.  It  is  only 
compatible  with  IBM  operating  systems.  However,  if  Panrisk 
had  shown  any  degree  of  success  in  the  market,  ether 
computer  vendors  would  have  undoubtedly  developed  similar 
systems  fcr  Honeywell,  Burroughs  and  others. 
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According  tc  its  advertising  brochure,  "Basically, 
Panrisk  is  the  application  cf  a  simple  formula  to  a  variety 
of  threats  whose  results  are  aggregated  to  give  a  complete 
picture  cf  an  organization’s  total  loss  potential  over  a 
period  of  time  "  [Bef.  43].  The  simple  formula  for  calcu¬ 
lating  the  Annual  Less  Expectancy  ALE  is  the  same  as  that 
given  in  FIPS  POB  65,  although  the  terminology  used  differs 
somewhat: 

ALE  =  single  occurrence  loss  x  occurrence  rate 
ie.  impact  x  frequency 


Skeptics  might  rightfully  question  using  a  computer 
system  for  such  a  calculation.  Panrisk  does,  however, 
produce  outputs  beyond  a  simple  ALE  -  it  can  format,  edit, 
and  generate  various  reports  cn  risk  information  to  be  used 
at  all  levels  within  an  organization.  Thus  the  package  may 
have  seme  merit  in  its  use  as  a  Management  Information 
System  (MIS)  or  as  a  Decision  Support  System  (DSS) .  The 
problems,  though,  arise  in  the  input  requirements.  In  erder 
for  the  system  to  become  useful,  the  organization  must 
provide  the  information  on  its  computer  resources,  threat 
probabilities,  vulnerabilities,  and  loss  potentials.  The 
provision  of  such  inputs  constitutes  the  most  difficult  part 
cf  conducting  a  risk  assessment.  Since  such  inputs  are 
largely  based  on  intuition  and  experience,  it  could  net  be 
expected  that  an  autemated  system  would  be  able  to  produce 
them.  In  general,  therefore,  taa  market  for  an  automated 
risk  assessment  will  be  extremely  limited.  In  the  fall  of 
1982,  Panrisk  was  taken  off  the  market  for  an  indefinite 
period  of  time. 

In  short,  an  autemated  system  is  no  better  than  a  manual 
one  cn  the  input  side  of  the  Hisk  Assessment  -recess. 
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Furt hermcre ,  organizations  must  exercise  caution  in  consid¬ 
ering  buying  off-the-shelf  Risk  Assessment  software,  since 
Sisk  Assessments,  by  their  very  nature,  must  be  uniquely 
tailored  to  an  agency's  needs.  From  the  standpoint  of  a 
CSS,  however,  an  automated  Risk  Assessment  could  greatly 
facilitate  a  user's  understanding  and  ability  to  handle 
budgeting  and  security  problems. 

B.  A  RISK  ASSESSMENT  AS  A  DECISION  SUPPORT  SYSTEM 

An  automated  Risk  Assessment  could  serve  as  an  excellent 
application  for  a  Decision  Support  System  (DSS)  .  According 
to  Sprague  and  Carlson  [Ref.  44]  the  characteristics  cf  an 
effective  DSS  include  :  1.)  Support  for  unstructured  (or 

semistructured)  problems;  2.)  Support  for  all  levels  of 
decision-making;  and  3.)  a  combination  of  analytical  techni¬ 
ques  and  data  presentation  techniques.  A  Risk  Assessment 
applicaticn  should  include  all  of  these  character istics . 

Sprague  and  Carlson  [Ref.  44]  discuss  three  components 
that  make  up  a  DSS  ;  1.)  the  dialog  model,  which  serves  as 

the  user  interface  tc  the  system;  2.)  the  data  model,  which 
controls  and  monitors  the  system  data  bases  via  a  data  base 
management  system  (OEMS)  ;  and  3.)  the  modeling  component, 
which  interfaces  with  the  data  and  dialog  models  to  perform 
mathematical  and  analytical  operations. 

The  dialog  component  of  a  DSS  is  perhaps  the  most  impor¬ 
tant  since,  from  the  user's  point  of  view,  it  functions  as  a 
virtual  system.  The  dialog  component  must  oe  able  to 
support  a  variety  cf  presentations  and  output  devices, 
different  inputs,  dialog  styles  and  communications,  and 
above  all,  must  be  user  friendly.  [Ref.  44]  For  a  Risk 
Assessment  application,  -his  means  that  the  user  (possibly 
the  command's  Security  Manager  or  ADP  Security  Officer) 


should  he  able  tc  select  the  way  it  which  he  inputs  ::  the 
system  and  the  way  in  which  outputs  are  displayed  on  the 
terminal  cr  printer.  Inputs,  which  may  include  keyboard 
inputs,  joysticks,  function  keys,  etc.,  will  be  constrained 
by  the  available  hardware,  but  outputs  can  have  several 
options,  largely  software-supported,  which  will  only  be 
constrained  by  the  user’s  and  builder’s  imaginations  and 
abilities.  Users  may  request  that  the  dialog  conventions 
used  include  guesticn/answer  sessions,  menu  selections, 
graphical  displays,  and  HELP  facilities  to  aid  in  supporting 
the  user's  knowledge  base. 

The  data  component  should  be  able  to  support  a  variety  of 
data  structures  and  types,  while  allowing  for  easy  data 
access  and  retrieval  [Ref.  44].  This  will  require  an 
extremely  versatile  and  capable  DBMS,  but  the  current 
state-of-the-art  is  such  that  these  requirements  could  be 
met  by  a  system  as  simple  as  DBASE  II  which  is  available  on 
mcst  microcomputers.  The  DBMS  of  a  Sisk  Assessment  applica¬ 
tion  will  require  that  the  user  be  provided  capabilities  tc 
generate,  update,  and  maintain  data  bases  composed  of,  at  a 
minimum,  threat,  asset,  and  vulnerability  information. 

The  ncdeling  component  must  provide  a  Model  Base 
Management  System  (MEMS)  to  allow  for  the  building  and  crea¬ 
tion  cf  new  models,  model  manipulation,  and  the  management 
of  a  library  of  models  [Hef.  44].  Tne  models  in  a  Sisk 
Assessment  TSS  will  be  used  to  calculate  ALEs  for  impact  and 
threat  categcries,  compare  various  ALEs,  and  mathematically 
combine  and  manipulate  ALE  figures.  This  component  could  be 
handled  by  the  programming  capabilities  of  DBASE  II. 


C.  DESIGN  SUGGESTIONS  FOB  A  DECISION  SUPPOBT  SYSTEM 


1  •  li;S  Pi  a  1  eg  Cc  ncor.en  t 

This  component  should  initially  allow  the  user 
several  presentation  options,  and  should  be  built  such  that 
later  refinements  and  enhancements  can  be  made  with  relative 
ease.  As  the  user  becomes  familiar  with  the  system  and 
feels  comfortable  in  using  it,  he  may  want  to  reduce  the 
system's  HELP  facilities  in  favor  of  more  speed  and  flexi¬ 
bility.  Initially,  however,  the  user's  Knowledge  base  will 
be  small  and  he  will  prefer  to  be  "led  through"  the  system. 
Assuming  the  user  is  at  least  famriiar  with  how  to 
initialize  the  system,  turn  the  terminal  on  and  logon,  he 
will  then  need  to  know  how  to  make  a  call  to  the  Bisk 
Assessment  DSS.  This  should  be  as  simple  a  type-in  as 
"Begin  Bisk",  "Co  Bisk",  or  "Risk"  followed  by  a  carriage 
return.  Ihe  initial  screen  might  look  like  the  one  shewn  in 
figure  5.1.  An  additional  option  might  involve  moving  a 
cursor  below  the  desired  operation  using  a  joy  stick,  or 
selecting  the  operation  with  a  light  pen.  Once  an  operation 
is  selected,  a  new  screen  showing  additional  options  within 
that  operation  will  be  displayed.  All  screens  beyond  the 
initial  one  will  provide  "Help"  options  as  well  as  options 
to  return  to  the  main  menu  or  end  the  session.  The  dialog 
model  might  also  present  the  user  with  a  canned  list  of 
assets,  threats,  and  vulnerabilities,  such  that  he  could 
delete  those  that  were  inapplicable  to  his  organization,  and 
add  those  that  did  apply.  This  would  not  only  serve  to 
increase  his  knowledge  base,  but  would  also  prevent  a  lot  of 
unnecessary  terminal  work. 

Output  representations  from  the  operations  should 
come  in  a  variety  of  formats.  Bar  graphs  might  prove  to  be 
desirable  representations  srnce  the  user  may  want  ccmpari- 


RISK  ASSESSMENT  DSS 


Select  the  desired  operation  by  typing  the  corresponding 
number  followed  by  a  carriage  return. 

1. )  Database  Update/Modi ficaticn 

2. )  Display  a  list  of  computer  system  assets 

3. )  Display  a  list  cf  computer  threats 

4. )  Display  a  list  cf  computer  vulnerabilities 

5. )  Calculate  Annual  Loss  Expectancy  (ALE)  values 

6. )  End  Session 

WAITING  : 


Figure  5.1  Initial  Screen  for  a  Risk  Assessment  DSS. 

sons  cf  various  ALEs  at  different  periods  of  time.  Figure 
5.2  illustrates  the  type  of  output  representation  that  might 
be  provided  by  a  Risk  Assessment  DSS.  Similar  output  repre¬ 
sentations  could  be  constructed  for  the  other  impact  areas 
as  well  as  for  threats,  assets,  and  vulnerabilities.  For  a 
DSS  cf  this  type,  most  users  will  desire  outputs  that  show 
comparisons  cf  relevant  information.  A  prioritized  list  of 
vulnerabilities,  for  example,  would  show  which  vulnerabili¬ 
ties  are  the  most  costly  in  terms  of  ALEs. 

2.  The  Data  Component 

The  Data  Component  will  be  perhaps  the  most  diffi¬ 
cult  to  understand  and  manage.  A  viable  and  capable  Data 
Base  Management  System  (DBMS)  will  be  required  to  maintain 
the  vast  number  of  files,  the  large  sizes  cf  the  files,  and 
the  links  between  the  files.  In  general,  an  effective  DBMS 
should  result  in  reduced  costs  of  building  and  using  the 
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NOTES:  The  ALE  OP  S63K  in  1979  represents  the  value 
calculated  for  the  completion  of  the  original  ALE. 

Due  to  the  addition  of  the  High  Speed  Communications 
System  in  1980,  the  increase  xn  system  vulnerabilities 
brought  about  a  proportionate  increase  in  the  ALE  (to 
J  8  0K|  • 

Installed  countermeasures  lowered  the  ALE  TO  S50K  in 
1981.  This  status  was  retained  through  1982. 

Existing  plans  should  decrease  the  ALE  TO  $45K  by  1983. 


Figure  5.2  Bar  Graph  Output  Representation. 

DSS,  increased  data  control  and  sharing,  and  reduced  data 
redundancy.  [Ref.  45]  In  building  the  D3KS  for  a  DSS,  the 
designer  will  chose  a  data  model,  which  is  a  "method  of 
representing,  organizing,  storing,  and  handling  data  in  a 
computer"  [Ref.  46].  The  three  parts  comprising  a  data 
model  include  :  1.)  a  collection  of  data  structures;  2.)  a 

collection  of  operations  that  can  be  applied  tc  the  data 
structures;  and  3.)  a  collection  of  integrity  rules  that 
define  the  valid  states  for  the  structures.  [Ref.  46] 

The  data  structures  for  a  Risk  Assessment  will  vary 
depending  or  the  type  of  file.  Separate  files  will,  at  a 
minimum,  be  required  for  computer  assets,  threats,  and 


vulnerabilities.  Figure  5.3  shows  the  fields  than  nig  hr  he 
contained  in  such  files.  Such  a  field  structure,  however, 
will  cbvicusly  result  in  a  great  deal  of  data  redundancy. 
For  example,  one  asset  will  be  exposed  to  several  threats; 
conversely,  one  threat  may  affect  several  assets.  The  most 
wasteful  method  would  be  to  list  every  threat  affecting  a 
specific  asset  and  include  them  as  part  of  a  record  in  the 
asset  file.  Similarly,  every  asset  affected  by  a  specific 
threat  would  be  included  as  part  of  a  record  in  the  threat 
file.  A  more  logical  method  of  constructing  these  files 
would  be  to  link  the  records  in  each  file  together  using 
some  type  of  relational  data  base  model  with  primary  and/or 
secondary  keys. 

liithin  the  data  model  it  will  be  necessary  to  define 
a  relationship  between  the  asset  and  threat  files  such  that 
it  can  be  determined  which  assets  are  affected  by  which 
threats,  and  within  which  impact  categories.  The  fields 
used  for  this  relation  will  be  the  IMPACT  CATEGORIES  (4 )  in 
the  asset  file,  and  the  IMPACT  CATEGORIES  AFFECTED  (4)  in  the 
threat  file.  By  defining  this  relation,  it  will  be  possible 
to  select  a  specific  asset,  link  it  to  an  applicable  threat, 
and  calculate  the  ALE.  This  type  of  linkage  could  be 
performed  by  a  JCIN  operation.  According  to  Kroenke,  "The 
JOIN  operation  is  used  to  combine  two  relations.  A  value  of 
one  attribute  in  the  first  relation  is  compared  with  a  value 
of  an  attribute  in  the  second.  If  the  two  values  have  a 
relationship  specified  in  the  join  operation,  then  the 
tuples  of  the  relations  are  combined  to  form  a  third  rela¬ 
tion."  [Ref.  50]  Thus,  an  asset  record  and  a  threat  record 
can  be  "joined"  by  issuing  a  command  such  as: 

ASSET  (IMPACT  CATEGORY  (4)  ^IMPACT  CATEGORY  (4)  AFFECTED)  THREAT 
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where  the  value  of  the  IMPACT  CATEGORY  field  in  the  asset 
file  is  compared  to  the  IMPACT  CATEGORY  AFFECTED (4)  field  in 
the  threat  file.  If  the  values  of  the  two  fields  are  equal, 
then  the  two  records  can  be  combined  to  form  a  single 
record.  In  this  way,  it  can  be  determined  that  the  record 
resulting  from  the  JOIN  operation  contains  an  asset,  an 
applicable  threat  from  a  specific  impact  category,  and  the 


ASSET  FILE  : 

asset  r.ame/asset  categcr  y/dsscnpt  ron/impact  categories 
(4)/impact  category  costs(4)/ 

THREAT  FILE: 

threat  name/description/impact  categories  affected  (4)/ 
frequency  of  occurrence/ 

VULNERABILITY  FILE: 

vulnerability  name/description/threats  exploiting/ 

COONTERHEASURE  FILE: 

countermeasure  name/description/cost  of  implementing/ 
vulnerabilities  af fecting/thrsat  frequencies 
affsctinq/ 


Figure  5.3  Field  Layout  for  Required  Files. 

frequency  of  occurrence  for  that  threat.  The  ALE  can  then 
be  calculated  by  multiplying  the  impact  value  times  the 
threat  probability. 

The  operations  that  will  be  applied  to  the  data  base 
files  shculd  include,  but  not  necessarily  be  limited  to, 
retrieval,  update,  modification,  combination,  and  summation. 
The  dialog  component  should  prompt  the  user  for  the  desired 
operation,  while  allowing  him  to  specify  such  details  as 


fils  tame,  field  name,  etc. 


The  integrity  rules  for  the 
files  may  be  kept  relatively  simple. 


field  values  in  the 
Values  for  impact 


category  may  easily  be  constrained  to  the  four  categories  of 
destruction,  aodif ication,  disclosure,  and  der.ial-cf- 
service.  Numeric  values  may  be  limited  to  a  relatively  wide 
range  of  values  within  certain  limits.  For  example, 
frequency  ratings  for  threats  may  contain  any  decimal  value 
between  .000  and  .999.  ALE  values  for  the  destruction  cate¬ 
gory  will  be  equal  to  the  asset  replacement  cost.  By  the 
same  token,  no  asset  ALE  may  exceed  its  total  replacement 


3.  The  Mode  ling  Com  non  ent 

’’The  modeling  component  is  the  primary  tcol  for 
supporting  many  of  tie  activities  that  decision  makers  will 
perform  in  the  process  of  making  decisions  and  solving  prob¬ 
lems"  [Ref.  47].  The  decisions  and  problems  for  a  Risk 
Assessment  application  will  evolve  about  the  calculation  of 
ALEs,  and  determining  the  areas  where  the  greatest  ALE 
reductior  can  occur.  Thus,  a  library  of  models,  consisting 
cf  permanent,  ad  hcc,  user-built  and  "canned"  models 
[Ref.  47]  will  have  to  be  made  available  to  the  user.  The 
permanent  models,  these  desired  by  most  users,  might  have 
the  capabilities  shewn  in  figure  5.4.  In  addition  to  these, 
model  generators  should  be  at  the  disposal  of  the  users  in 
erder  that  they  may  generate  and  structure  tneir  own  models. 
Optional  models  that  may  be  requested  involve  activities  for 
projection,  deduction,  analysis,  creation  of  alternatives, 
comparison  of  alternatives,  optimization,  and  simulation. 
[Ref.  48] 

4.  Integration  cf  Comp onents 

"The  modal  base  and  its  management  system  must  be 
integrated  with  the  dialog  directly,  to  give  the  user  direct 
control  ever  the  operation,  manipulation,  and  use  of  models" 
[Ref.  49].  By  the  same  token,  there  must  be  a  tight 


there  mus- 


be  a 


THREAT  MODEL  : 

a'^aTSuIaHSn  ,  summation,  and  analysis  of  the  ALEs 
contributed  to  by  specific  threats 

ASSET  MODEL  : 

TKe~HEs  attributed  to  specific  assets. 

VULNEE  ABILITY  MODEL  : 

an  analy sis“a n3”peTcenta  ge  calculation  of  the  ALEs 
caused  by  specific  vulnerabilities. 

COUNTERMEASURE  MODEL  : 

aS”anaIyIIo“of  EHfXLE  reductions  that  might  be  trouchJ 
about  by  the  implementation  of  specific  countermeasure; 


Figure  5.4  Permanent  Model  Capabilities. 


coupling  between  the  modeling  component  and  the  data  compo¬ 
nent.  "With  this  direct  linkage,  models  can  be  updated  as 
the  data  values  are  updated,  and  modified  or  restructured 
when  the  data  have  changed  enough  to  require  it"  [Ref.  49]. 
The  components  and  the  possible  linkages  among  them  may  be 
depicted  as  in  figure  5.5. 
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Figure  5.5  Integration  of  DSS  Components 


0.  LIMIT1TI0NS 


The  construct  ion  and  design  of  the  dialog  and  modeling 
components  can  be  made  with  relative  ease.  It  is  in  the 
design  and  development  of  the  data  component  that  the 
majority  of  the  difficulties  will  arise.  This  will  create 
additional  problems  in  that  a  complete  and  capable  DBMS  is 
critical  tc  the  correct  functioning  of  the  dialog  and 
modeling  components.  The  DSS  can  not  function  without  the 
complete  integration  cf  the  three  components. 

The  user  is  also  confronted  with  severe  difficulties  in 
the  actual  construction  of  the  databases.  while  the 

designer  may  be  able  to  provide  an  efficient  mechanism 
through  which  databases  may  be  created  and  updated,  the  user 
may  be  frustrated  in  his  attempts  to  collect  the  data  needed 
tc  include  in  the  databases. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


This  thesis  has  examined  various  facets  of  the  concepts 
cf  risk  assessment.  The  subject  is  exceedingly  complex  and 
affects  virtually  all  segments  of  organize tions  which  employ 
computers  tc  accomplish  their  objectives.  The  multitude  of 
directives  promulgated  by  various  agencies  of  the  federal 
government  attest  tc  the  attention  being  focused  cn  risk 
assessments.  The  quality  of  the  direction  provided  in  this 
area  is  generally  good;  however,  the  instructions  are  often 
lengthy  and  sometimes  written  in  a  style  difficult  to 

follow.  The  most  important  point  expressed  in  Chapter  Two 
is  the  realization  that  competent  guidance  concerning  risk 
assessments  exists.  The  level  of  user  awareness  regarding 
the  availability  of  this  guidance  must  be  raised.  As  the 
federal  government  in  general,  and  the  Department  of  the 
Navy  in  particular,  allocate  more  and  mors  funding  to 
computer  systems  resources,  organizational  dependence  upon 
computer  services  will  grow.  This  fact  necessitates  a 

corresponding  effort  towards  ensuring  the  security  of 
computer  systems.  For  example,  the  Naval  Regional  Data 
Automation  Center,  San  Francisco  (NARDAC-SF)  allocated 
several  personnel  in  its  Management  Control  Department  to 
conduct  a  risk  assessment  at  that  facility.  Their  study 
resulted  in  a  tctal  annual  loss  expectancy  for  NARDAC-SF 
amounting  to  over  33.8  billion.  it  should  be  noted  that  an 
astronomical  figure  like  3  8.8  billion  in  no  way  represents 
the  actual  expected  value  of  losses  during  a  given  year. 
Rather,  it  is  the  aggregate  ALE  resulting  from  totalling  the 
individual  ALE’s  in  each  impact  area.  These  figures  indi¬ 
cate  the  relative  priorities  to  be  placed  on  security 

measures  in  different  areas.  Clearly  assets  evaluated  at 
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relative  sums  on  this  magnitude  warrant  significant  security 
appraisals.  This  attention  and  analysis  is  precisely  the 
driving  influence  behind  the  risk  assessment  directives. 
Further  dissemination  to  the  proper  individuals  with  appro¬ 
priate  authority  should  increase  security  efforts  in  this 
area. 

Several  aspects  associated  with  contracting  for  risk 
assessment  services  were  considered  in  Chapter  Three. 
0PNAVINS1.  5239.  1A  directs  all  commands  with  computer  system 
assets  to  conduct  a  risk  assessment.  The  amount  of  effort 
required  tc  conduct  a  risk  assessment  may  force  smaller 
commands  to  seek  outside  assistance.  Naval  Regional  Data 
Automation  Centers  (NABDACS)  are  available  to  provide  assis¬ 
tance.  However,  the  various  NAHDAC's  around  the  country  are 
staffed  at  different  manning  levels,  so  the  amcunt  of  assis¬ 
tance  each  command  is  able  to  provide  may  vary.  CCMNAVDAC 
maintains  a  list  of  contractors  approved  to  conduct  risk 
assessments  or  tc  provide  assistance  to  commands  conducting 
their  own  risk  assessments. 

As  the  framework  for  conducting  a  risk  assessment  at  the 
Naval  Postgraduate  School  demonstrates,  the  task  of  actually 
conducting  cne  is  certainly  non-trivial.  Compiling  a  list 
of  all  systems  assets  and  procedures  and  assigning  impact 
values  tc  them  is  a  complicated  ,  time-consuming  endeavor. 
Of  equal  difficulty  is  determining  a  list  of  all  potential 
threats  and  their  associated  frequency  ratings.  It  requires 
personnel  experienced  in  the  areas  of  computer  operations, 
finance  and  administration.  The  computation  cf  the  annual 
loss  expectancy  and  its  use  in  evaluating  the  potential 
benefits  of  countermeasures  is  also  an  effort  which  requires 
a  great  deal  of  precision  and  judgement.  The  ADP  Security 
Manual  provides  a  reasonably  clear  explanation  of  these 
steps  and  good  background  material  which  is  beneficial.  The 


manual  alsc  provides  examples  for  each  type  of  computation. 


In  censral,  the  emphasis  currently  being  devoted  to 
security  and  risk  assessments  in  the  Navy  is  very  timely  and 
prudent.  Given  the  dependence  of  the  Navy  on  computer  tech¬ 
nology  for  such  services  as  supply  processing,  tracking 
spare  parts  failure  and  usage  rates,  environmental  fore¬ 
casting,  payroll  and  personnel  records  and  a  myriad  of  ether 
tasks,  it  is  easy  to  imagine  the  havoc  which  could  be 
created  if  these  services  are  disrupted.  The  risk  assess¬ 
ment  program  is  a  positive  effort  to  study  the  state  of 
security  with  respect  to  a  command's  computer  systems, 
quanitfving  the  assets  and  threats  and  using  this  data  to 
evaluate  countermeasures.  The  criteria  for  evaluating  coun¬ 
termeasures  is  cost-effectiveness.  The  risk  assessment 
procedure  appears  to  be  a  logical  manner  in  which  tc  deter¬ 
mine  the  relative  impacts  of  various  threats  on  system 
assets  utilizing  this  criteria. 

It  would  be  difficult,  if  not  impossible,  to  quantify 
the  exact  value  of  the  risk  assesment  itself.  Since  the 
overall  purpose  of  a  risk  assessment  is  to  justify  counter- 
measures  in  order  to  prevent  disasters,  hopefully  potential 
disasters  will  be  averted.  Certainly  attention  will  be 
directed  tc  problem  areas  in  security.  However,  even  though 
this  process  has  net  been  quantified,  the  logic  providing 
the  impetus  to  conduct  such  assessments  seems  well-grounded. 

No  procedure  in  this  area,  however,  will  be  successful 
unless  it  receives  a  sufficient  amount  of  command  attention. 
The  general  tendency  for  most  commands  is  to  treat  the 
security  and  reliabiltiy  of  computer  services  in  a  "taken- 
for-granted”  manner.  The  magnitude  cf  the  potential 
disasters  due  to  the  loss  cf  computer  services  makes  a 
change  in  this  type  cf  care-free  attitude  imperative.  The 
requirement  directing  all  commands  with  computer  systems  to 
conduct  a  risk  assessment  is  an  important,  viable  means  of 


correcting  this  attitude.  It  forces  commands  tc  make  a 


rational#  thoughtful  analysis  of  its  systems  as  directed  by 
0PNAVINS1  5  23  9. 1A.  To  derive  maximum  profit  from  this 
procedure,  the  command  should  ensure  that  all  concerned 
personnel  are  aware  of  the  significance  of  conducting  this 
exercise.  If  the  risk  assessment  procedure  degenerates  into 
a  "paperwork  drill"  conducted  by  some  personnel  in  the  lower 
levels  of  the  command,  then  the  results  may  be  virtually 
wort  hless. 

A.  SUGGESTIONS/RECOMHEH DAT  IONS  FOR  IMPROVEMENTS 

As  mentioned  previously,  the  risk  assessment  at  the 
Naval  Postgraduate  School  can  be  completed  by  students  in 
the  various  Computer  Systems  and  Management  curricula.  This 
situation  would  provide  many  benefits  of  both  an  academic 
and  practical  type,  net  the  least  of  which  are: 

1)  Provide  participating  students  with  a  fundamental 
knowledge  of  the  computer  security  problem. 

2)  Save  the  Naval  Postgraduate  School  a  considerable 
amount  of  money. 

The  remaining  recommendations  are  directed  at  the  larger 
scale  problem.  A  measure  which  would  improve  both  the  effi¬ 
ciency  and  effectiveness  of  the  risk  assessment  procedure 
might  be  to  establish  assist  teams  at  NARDAC's  throughout 
the  country.  These  teams  would  be  available  to  assist 
commands  desirous  of  conducting  risk  assessments  by 
providing  expertise  in  security  areas  not  normally  encoun¬ 
tered  by  activities  as  part  of  their  normal  routine.  The 
establishment  of  these  teams  would  serve  several  purposes: 

1)  Erovide  a  body  of  experts  to  conduct  risk 
assessments  and/cr  to  provide  assistance  to 
commands  conducting  them. 

2)  Enable  commands  throughout  the  Navy  to  conduct 
their  own  assessments  without  being  forced  to 
contract  for  services. 
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Another  area  which  could  be  improved  is  to  provide  aore 
definitive  guidance  to  commands  concerning  the  value  of 
systems  assets.  Central  agencies  in  Washington,  D.C.  such 
as  the  Automatic  Data  Processing  Selection  Of  fice  ( ADPSO)  and 
the  Naval  Data  Automation  Command  (NAVDAC)  maintain  approval 
authority  and  inventories  of  major  systems  throughout  the 
Navy.  These  agencies  should  possess  data  concerning  the 
costs  of  various  types  of  hardware,  software,  and  possibly 
data.  The  dissemination  of  this  data  could  eliminate  seme 
of  the  estimating  required  to  get  values  for  systems  assets. 

A  final  recommendation  concerns  the  subject  of  an  auto¬ 
mated  risk  assessment  package.  Chapter  Five  has  presented 
the  preliminary  design  for  a  Risk  Assessment  Decision 
Support  System.  A  feasibility  study,  conducted  perhaps  at 
one  of  the  NASDAC's,  might  be  undertaken  to  assess  whether  a 
DSS  of  this  type  would  be  beneficial  and  cost-effective  on  a 
Navy-wide  basis.  To  satisfy  a  wide  range  of  users,  this  DSS 
would  have  to  be  extremely  user-friendly  and  capable  of 
accepting  a  variety  cf  inputs.  It  may  be  that  the  inventory 
of  Navy  computer  systems  is  so  varied  that  this  type  of 
management  support  aid  would  not  be  practical  on  such  a 
large  basis.  However,  the  potential  benefits  cf  this  tool 
merit  seme  investigation. 
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This  is  at  example  of  OPNAV  5239/8 


THREAT  AND  VULNERABILITY  EVALUATION  WORKSHEET 

I 

'  THREAT  NAME  ""  — - 


2.  DESCRIPTION,  ffXANFt^S,  AMO  JUSTIFICATION  BASED  OM  CXJSTIMO  COUNTC*M£ASU*CS  ANO  VULMCMBILlTIKS . 
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This  is  an  example  of  OPNAV  5239/10. 


opmavinst  wt.ii 


additional  countermeasure  evaluation  worksheet 


LIST  OF  REFERENCES 


Hammer .C. , 
Security  Inst 


Security. 


Computer 


Wylie,  I.,  Orgarizinq  for  Security,  Computer  Security 
Conference  ,-5oiTon,T  9^7 - 


Boyer ,  T. , 
Management 


Continaenc y  Planning:  An  Opportunity  For  DP 
,“C3Iputer  Security' institute^  TT87.  “ 


Parker,  D.,  The  Pot ential  Effects  of  Electronic  Fund 
Transfer  Svsiea  “on  “TJaticnal”  “Security,  “  “IsItT 
Tnlernat  io  naI7~3un  e  1330.  “ 


Head,  R.,  Federal  Information  Systems  Ha nagement: 
Issues  and  Directions  ,  The  Sfoprinqs- Institute .  1981 , 
£77" 


Office  cf  Management  and  Budget  Circular  No.  A-71 
promulgated  27  July  1  978. 


Browne,  P. ,  security :  Computer  Center  Audits.  A? IPS 
Press,  197  9,  £7777  “ 


Office  of  Management  and  Budget,  Security  cf  Federal 
automated  information  systems.  OdB  Circular  no.  A- 7 IT 
27”3uIy“T978'T - L - 


Browns.  ?.  Security:  Computer  Center  Audits,  AFIPS 
Press,  1979,  ££77=777  - - 

Ibgd. 

Ibid. 


Head,  R.V.,  "Federal 
Sinews  of  Government", 
February  1981. 


ADP  Systems  :  Atrophy  in  the 
Government  Executive .  ~  d.  36, 


Haase,  W.w. ,  "Data  Security  Considerations  in  the 
Federal  Gcyernment",  Seventn  Annual  Computer  Security 
Conference,  p.  5,  November  1980. 


Department  of 
Automatic  Data 
57TJ137YB7“p7“77 


Defense,  Security 
Processina  (TSV]  3vst 
T5“7ecea3er  7772 .  — 


Requirements  for 
ems,  73T5“T>irect ive 


Office  of  Management  and  Budget,  Responsibilities  for 
the  maintenance  of  records  about  individuals  o7 
7 ed er aT~a q  sncT e s .  UflB  Circular  no  .~5-10H,  p7"T7~ T“JuIy 


Ibid. ,  p .  13. 


Ibid. ,  p.  3. 


Ibid .  ,  □ .  6 . 


National  Bureau  of  Standards,  Guidelines  for  Autc  me  tic 
Data  Fro  cess  in  q  Physical  Security"  a  na“1isTc  Management. 
■FlHeriI"Tnform  at  ion  "Processing  standarcls"  FScxicat  ion 
31,  fcreward,  June  19  74. 


Ibid.  ,  p.  23. 


Ibid. ,  p .  5. 


Ibid.,  p.  10. 


Ibid.,  p.  13. 


Office  of  Management  and  Budget,  security  of  Federal 
automated  information  systems,  0M3  Circular  no.  A-7T , 
pT~lT~T7-JuIy~117H7 - L - 

Ibid. .  p.  5. 


National  Bureau  of  Standards,  Guideline  for  Automatic 
Data  Processing  Risk  Analysis ,  "Federal  Information 
Frcce ssi ng“S ta naarls  Publication  65,  p.  1,  August 
1979. 


Ibid . ,  p .  7 . 

Ibid.,  p.  10. 


Ibid. ,  p.  9. 


Ibid. .  p.  12. 


Chief  cf  Naval  Material.  Contractor  Support  Services, 
NAVMAI  INSTRUCTION  420 Q. 50CT~T"7eEruary  1732 .  "pT~"T7 


32. 


UNCLASSIFIED 
Commanding 
.  Subject: 
Accredit  a*,  ion 


33.  Commander,  Naval  Data  Automation  Command,  Department 
of  the  Navy  ACE  Security  Manual  (Draft)  ,  fllvDlEI K5T 
55  VC71X,  “77797 - - - 


Commander,  Naval  Data  Automation  Command,  Procedures 
for  Fsguestinq  Services  from  Navy  Regional-  Data 
lut  cm  alii  on  Centers  TNI'Sd  ACtrT  ““TvDAC  rSSYSUCTTUTT 
o71TT7T3C7-P-  27“Tr7ovemSer-797§ . 


35. 

Sprague, R.  and  Carlsen,3.,  3uiidirg,  Effective 
Su£j:ort  Systems.  Pren  t ics-HaiI7Iac.  ,“T9H27-p7 

Decision 

1137 - 

36. 

OENAVINST.  5239. 1A  dated  3  August  1982. 

37. 

Ibid. 

38. 

NAVEGSCOLINST.  5400. 2A  dated  1  April  1982. 

39. 

OENAVINST.  5239. 1A  dated  3  August  1982. 

40. 

Fitzgerald,  J  - ,  ED?  Risk  Analysis  For  Co 

Planning,  SDPACS  Newsletter.  August  79737 

nti  agencv 

41. 

Gerterick.  D..  Security  Risk  Analysis, 

Newsletter,  April  19797” 

ED?  ACS 

42. 

OENAVINST.  5239. 1A  dated  3  August  1982. 

43. 

"Introducing  Panrisk",  Panscphic  Systems,  Inc 

.  ,  198  0. 

44. 

Sprague,  R.  and  CarlsenrE.,  Building  Effective 
Support  Systems,  Pren  tice-HaU7Tnc. , "T9 327 

Dec is  ion 

45. 

Ibid. .  p.  224. 

46. 

Ibid. ,  p.  225. 

47. 

Ibid. .  p.  262. 

48. 

Ibid . ,  p .  26 0  . 

90 


IN I 2IAL  DISTRIBUTION  LIST 


Nc.  Copies 

1.  Defense  Technical  Information  Center  2 

Cameron  Station 

Alexandria,  Virginia  22314 

2.  Library,  Code  0142  2 

Naval  Postgraduate  School 

Monterey,  California  93  940 

3.  LECR  Gary  Hughes , SC, USN  1 

Naval  Supply  Center  Puget  Sound 

Bremerton,  Washington  98314 

4.  Commanding  Officer  1 

ATTN:  Cdr.  E.  Perkins 

BLDG.  1 A 

Naval  Data  Automation  Facility 
Newport,  Rhode  Island  0284  1 

5.  Lt.  Margaret  A.  Elack  2 

BLDG.  1 A 

Naval  Data  Automation  Facility 
Newport,  Rhode  Island  0  2841 

6.  CER .  Orcanek  1 

Cede  44 

Naval  Postgraduate  School 
Monterey,  California  93940 

7.  George  B.  Gill  1 

AEP  Security,  Code  007A 

Fleet  Numerical  Oceanography  Center 
Monterey,  California  93940 

8.  Lt.  Martin  F.  Doherty  2 

Surface  Warfare  Officer  Deoartment  Head  School 
Naval  Education  and  Training  Center 

Newport,  Rhode  Island  0  2841 

9.  Prof.  N.  Lyons  1 

Cods  54 LB 

Naval  Postgraduate  School 
Monterey,  California  93  940 

10.  LCDR.  J.  Berquist,  SC,  OS  N  ! 

Cede  54ZA 

Naval  Postgraduate  School 
Monterey,  California  93  940 

11.  Naval  Postgraduate  School  1 

Computer  Technology  Curricular  Office 

Code  37 

Monterey,  California  93  940 


92 


